Significant fragmentation resulting in a noticable performance hit is unlikely in Linux.

Unlikely is not the same as impossible.

With all the new and varied ways Linux is being used, from super-computers to Tivos and even wristwatches it’s a safe bet that someone somewhere is running something that is constantly saving and deleting files of odd sizes on a mostly full hard drive.

Bringing a defrag script into the Linux world only makes Linux a little better, even if it doesn’t do a huge amount of good for the average user it certainly hurts no-one.

So why flame someone whom took the time to write a script and share it for the benefit of others?

Trolls only discourage the writing and sharing of new open source software. Even if the author being flamed doesn’t take it to heart, any potential new OSS programmer could read posts like that and decide it’s better not to participate.

To put it very simply, while not entirely accurate, Linux will NOT split a file over a disk surface, instead, it finds the most appropriate space.

Check the following post:
http://blog.linuxoss.com/2007/04/15/why-doesnt-linux-need-defragmenting/

Consider a number of file cabinets on your office. You have a file that you need to store in your cabinets. Unfortunately, the file is far to large to fit in the first cabinet. So, at this point, you have two options:

If you’re going to take the road of the NTFS/FAT family of filesystems, then you immediately begin pulling papers from your file, and placing them in the first available spot in the cabinets, until your file is exhausted, meaning your file will probably exist in several cabinets, if they were already filled.

If you’re going to take the road of the ext2, ReiserFS, XFS, JFS, etc. family of filesystems, then you scan the cabinets looking for the largest chunk of contiguous cabinet space to fit the file. Chances are high, that you’ll find space to fit the entire file together, rather than splitting it out across separate cabinets.

Now, let’s look at the two algorithms’ results. In the first (NTFS/FAT), a single file is fragmented across the disk. As you continue to write and delete data, the filesystem becomes more and more fragmented until I/O performance becomes a serious concern. In the second algorithm, the inodes are fragmented, but individual files are not. This becomes less likely of a concern, as inodes have a lookup table in the filesystem superblocks, making it easy to locate the data blocks on disk. Although the inodes may not be contiguous, the file data blocks are. It is substantially more difficult to achieve poor I/O performance in this manner.

Lastly, take a look at the role of the e4defrag command. Not only does it defrag data blocks (fragmented files), but it also defrags inodes which is the more common scenario (this is what fsck is reporting, not fragmented files).

While the intention of your article is good, the understanding of lower level operations needs to be studied. The ext2 family of filesystems, and other popular OSS filesystems, do not generally suffer from block fragmentation, just inode fragmentation. This is generally fine, as inode fragmentation just won’t lead to poor I/O performance, keeping the user and system admin happy. However, with that said, a full disk will ultimately lead to block fragmentation in the end, even on ext2 based filesystems.

1. files in a directory [seek time for directory listings,
nowadays _mostly_ fixed in the various filesystems, e.g.
by trees: see e.g. mkfs.ext3: dir_index]

2. blocks of a file: continuous or scattered:
this concerns both the placement of inodes AND the data blocks.
And fsck does only tell part of the story: “non-contiguous inode”
… . (still too simple: block groups, etc “should”(?) also be
considered; as should be striping, physical disk layout,
raid issues, bad block remapping by the drive, etc, pp)

3. tail packing or fragments: placing multiple partial blocks into a
single block. Ext3 doesn’t fully support this, so its
a non-issue for ext3. Aix4’s JFS is an example of such
a FS. [basically this always violates #2 by trading
a tiny bit of disk space for an extra read and a
possible extra head movement. Which should make this
another obselete issue, I'd assume]

Basically the article only is only a very simple (and IMHO valid)
experiment concerning type 2 fragmentation.

Ignoring the loop issue, the improvements shown aren’t really worthwhile with *server-style* filesystems, though one rule of thumb might be worthwile to remember:

Do not allow a filesystem with _*changing*_ data to fill up beyond say 90% (or delete some huge files if you did). That’s basically the only way to get hit with REALLY significant degradation.

Another note: consider traditional usage cases and development constraints when comparing fragmentation issues for different filesystems on different operating systems:

Windows filesystems and their fragmentation issues are from a desktop heritage (i.e. outage is cheap, powerdown may happen at any moment), while Unix filesystems always were server filesystems, so reducing severe degradation and allowing long uptimes was always a far more important influence for unix filesystem design.

Nice article, thanks. I have to say that I am not sure how useful this would be in my environment but I will be checking.

I think a lot of people replying need to remember YMMV, just because this does not apply to your environment does not mean this is not a worthwhile article.

Take care all.