Hey, guess who got bored last weekend on a robotics trip and decided to write a Linux defragger?
A quote from the README:
Defrag is a set of scripts designed to measure and cope with filesystem fragmentation. Currently, it only consists of "defrag".
Fragtool's syntax is:
/usr/sbin/defrag [-h] [-n passes] [--passes n] [-t threshold] [--threshold n] [-a] [--analyze] [--help] path
When invoked, defrag will analyze the given path recursively for file fragmentation and print out a summary of its findings. Next, it will ask you if you'd like to run any defragmentation passes.
Fragtool also takes an optional passes argument, which makes it perform fully non-interactively. Positive number of passes will perform that many passes and exit, while zero passes will just print out the summary and exit.
Q: A defragger? For Linux? Are you crazy?
A: No, I certainly am not. Under certain circumstances, even the most fragmentation-resistant filesystems get fragmented. Don't believe me? Look around with defrag. Whether or not filesystem performance is affected can be debatable at times, though I personally have to say that when a 300MB torrent is split into 5000 fragments, read speed is drastically affected.
Q: What filesystems is it compatible with?
A: Any filesystem that Linux can write to. The tool is pretty filesystem agnostic, but does require that filefrags be able to understand the layout of files.
Q: Is it safe to use?
A: Defrag works great in the author's extensive testing with all kinds of files. However, I cannot be certain that it does not damage your setup, so use with caution like any other fragmentation tool. As long as you use a journaling filesystem, the process is atomic. Before defragging a file, we make sure that it is not open for write access. Also, before doing the in-place replacement at the end of a defrag, we make sure again that the file has not changed. These are the same precautions that the tried-and-true xfs_fsr XFS defragger uses.
Q: Is it safe to interrupt?
A: Yes, defrag will safely clean up after itself. In the case of abrupt termination (SIGKILL, power off, etc), fragtools will leave behind ".defrag" temporary folders on the filesystem. They are owned by root with a mode of 000, and can be easily located and cleaned up using "find".
Q: Does it resume where it left off after an interrupt?
A: No. It doesn't. It sounds cool though.
Q: Is it effective?
A: Depends on the particular filesystem it is being used on. The defragmentation algorithm either fully defragments a file on the first try, get progressively better in subsequent passes, or is unable to make any improvement for infinite numbers of passes. Usually, if the file is not defragmented by the 10th pass, it's a lost cause. But in general, you will see improvements on fragmented filesystems. You will not see great improvements if you obsessive-compulsively run the defragger on the same set of files. Get a life.
Q: How many passes should I run?
A: Generally, anything from 5-10 passes is good. If it's not defragmented by then, chances are that your filesystem does not have enough contiguous free space to defragment the file. Go by what you feel is good after running the 5-10 passes.
Q: I run XFS. Should I use this, or xfs_fsr?
A: If you are interested in defragmenting, use xfs_fsr. It is faster by orders of magnitude, not to mention that it is production-tested. If you would like to get fragmentation statistics, defrag is the perfect tool to get that.
Q: If you think this is so great, why hasn't anyone else written a defragmenter for Linux?
A: Others indeed have. A user at forums.gentoo.org wrote a perl fragmentation checker, and Con Kolivas wrote a bash script defragger. Fragtool was inspired by both of these efforts, and aims to intelligently combine the two to perform the task more intelligently (i.e. do not try defragmenting defragmented files, do not make fragmentation worse than before, etc).
jdong@jdong-laptop:~$ sudo defrag /usr/sbin
Building list of files to analyze... done!
Analyze finished. 1.0 % fragmentation (2 files), 13.3 average frags/MB
How many passes to run? 
===> Pass 1 of 10 <=== Remaining Fragmentation 26/26 (100%)
Pass 1 of 10, 1/2 (50%): 13.9 frags/MB /usr/sbin/sshd
301372 100% 23.29MB/s 0:00:00 (1, 100.0% of 1) Fully defragmented!
Pass 1 of 10, 2/2 (100%): 12.7 frags/MB /usr/sbin/gdm
246864 100% 51.04MB/s 0:00:00 (1, 100.0% of 1) Improved: (12.7 --> 8.5)
===> Pass 2 of 10 <=== Remaining Fragmentation 8/26 (31%)
Pass 2 of 10, 1/1 (100%): 8.5 frags/MB /usr/sbin/gdm
246864 100% 68.06MB/s 0:00:00 (1, 100.0% of 1) Fully defragmented!
===> Pass 3 of 10 <=== Remaining Fragmentation 0/26 (0%)
===> Pass 4 of 10 <=== Remaining Fragmentation 0/26 (0%)
===> Pass 5 of 10 <=== Remaining Fragmentation 0/26 (0%)
===> Pass 6 of 10 <=== Remaining Fragmentation 0/26 (0%)
===> Pass 7 of 10 <=== Remaining Fragmentation 0/26 (0%)
===> Pass 8 of 10 <=== Remaining Fragmentation 0/26 (0%)
===> Pass 9 of 10 <=== Remaining Fragmentation 0/26 (0%)
===> Pass 10 of 10 <=== Remaining Fragmentation 0/26 (0%)
========= COMPLETE ===========
Remaining Fragmented Files:
Frags/MB Before: 26.66
Frags/MB After: 0.00
Improvement: 100.0 %
Attached is a tarball containing both debianized source code (written in Python) and a .deb package for simpler installation. There is only one file (defrag) that needs to be installed. It should be very safe to use (follows the trusted XFS defragger algorithm) on any filesystem, but I don't guarantee that it'll be flawless on every setup. Don't run passes over crucial data unless you have backups, I guess
The fragmentation numbers printed are in Frags/MB. I think that makes more sense than just counting fragments, so you don't spend time defragging huge files that will naturally be slightly fragmented.
Do _not_ obsessive-compulsively run passes trying to achieve perfection. By default, the defragger counts files with less than .5frags/MB as unfragmented. This can be overridden with the -t parameter. Do it wisely... If you try too hard to defrag, what will happen is that while files may defragment, free space will become fragmented in the process, which will ultimately lower write performance.
This is not a full defragmenter (i.e. free space consolidation, directory reorganization), but just a file defragger.
The source code is under the GPL, and you are welcome to play around with it. I'm open to suggestions and contributions. The working directory of the source archive is already a bzr 0.8 knits repository, so it's ready for decentralized commits.
I will be publishing the head branch as soon as I find a place to host it, as my system will not take the bandwidth hit and Launchpad supermirror does not support Knits yet.