SDB:EXT2 Fragmentation

Situation:

You want to defragment the EXT2 file system.

Cause:

During the file system check, the message 'x% non-contiguous' files is displayed.

Solution:

Thanks to Kristian Koehntopp for this information.

Defragmenting does not help at all since, after the fragmentation, the file system will quickly reach again the fragmentation level suitable for the utilization of the file system and will remain there.

In addition, the length of the fragments plays a significant role. Linux uses a readahead of 16 blocks inside the kernel. This means that, if a file is sequentially read (well over 95% of all read accesses!), Linux reads up to 16 blocks ahead in order to "pre-heat" the cache inside the kernel, hoping that these blocks will be immediately required by the program in question.

If the fragments are thus larger than 16 blocks (and most are, see below), then it does not matter whether the file is fragmented or not, since the seek in the readaheads goes down. Only fragments smaller than 16 blocks negatively affect the read performance.

The ext2 file system writes files with a kind of writeahead, too, i.e. with preallocation. When you write a block in an ext2 file system, the file system occupies immediately up to 7 further successive blocks for that file. Two competitive write accesses to a directory would not produce blocks like:

121212121212

but rather a block sequence similar to:

1ppppppp2qqqqqqq

whereby 1 and 2 represent written blocks for the files 1 and 2, respectively, and p and q are blocks booked in advance for the files 1 and 2. The result of 1 and 2 being simultaneously extended is:

11111111222222221ppppppp2qqqqqqqq

and so on. In this way, the harmful (small) fragmentation is avoided to the possible extent. The whole process is a generalization of the fragment/block procedure of the BSD Fast Filing System.

Moreover, as a user on a multi-tasking system you must distinguish between performance and throughput: performance is the maximum MB per second a user with a single process can get from the disk; whereas throughput is the rate at which a processor can work (comprising all users and processes) expressed in MB per second.

In multi-tasking systems, the throughput is often much larger than the performance. Linux has algorithms that increase the throughput of the system, not its performance. For example, accesses to the hard disk located in the disk's wait are sorted in ascending order according to the block number. By using a sawtooth algorithm, the head of the disk climbs to the high block numbers and services the requests, and subsequently goes down in one long seek in order to undertake the next round. (No, I do not mean the elevator algorithm; with it, the latency/service times would be too high and the algorithm is not fair anyway). In addition, successive requests for the same Linux process are grouped in a larger request (clustered).

Such an arrangement results in the read accesses not taking place according to the order and size produced by the process, but according to an order and size easy for the disk to handle. In this way, the effects of a large fragmentation are covered to a large extent - only small fragments negatively affect the throughput.

Finally, you also have to consider the buffer cache of the operating system, i.e., on the second read attempt, everything comes out from the RAM anyway and the data arrangement on the disk does not matter.

Defragmentation is a waste of time, Kristian . This information comes from KRIS@KOEHNTOPP.DE <keyword>ext2,fragment,defrag</keyword>