Fragmentation: Linux kernel untar
We speak about fragmentation when a single file is split into multiple, noncontiguous parts called fragments. As with standard mechanical drive each head seek is very expensive (5-15 ms on most product, while the CPU clock period of a entry-level process is measured in ns, some 6 orders of magnitude lower) fragmentation is #1 enemy for any filesystem. An heavily, random fragmented filesystem will be much slower than a low fragmented one.
This problem can be addressed by using at least one of these two strategies:
-
running, on a regular base, a defragmenter (a software specifically written to reorganize file on disk, so that the various file fragments are reorganized in greater, single contiguous fragment);
-
implementing some non-fragmenting logic directly within the filesystem (so that for each write the filesystem try to use contiguous disk space).
The first solution is surely quite uncomfortable (as we must deal with periodic defragmentation), but it can implement some complex logic to almost totally eliminate fragmentation. The second possibility is much more transparent (we haven't to do anything special), but can be more fragmentation-prone.
Windows system choose the first approach: starting from Win2000, Microsoft include an on-line defragmenter for NTFS volumes.
Linux filesystem historically choose the second path: all the benchmarked filesystems integrate some non-fragmenting logic and not all filesystems have an on-line or even off-line defragmenter. XFS is the only one to have a stable, online defragmenter at the moment (EXT4 has a beta online defragmenter called e4freefrag but it is not included in any distribution at this time).
So, how these filesystems behave regarding fragmentation? Let's start with a simple, common task: untar the Linux kernel. This operation sequentially creates over 32000 files:
As you can see, in this simple operation the recent filesystems are perfect, with an average of one fragment per file. The aging EXT3 filesystem (the only one without delayed allocation capability) is quite worse but, after all, it is not so bad.
UPDATE: preparing the system for another benchmark, I noticed that, in contrast to what written in Fedora 14 documentation, write barriers were non enabled on EXT3 filesystem. Please read the updated "Conclusions" page.