File Fragmentation

System performance can suffer when files are fragmented. Why then, is it allowed to happen? It happens because it is a side effect of allowing multiple accesses to a disk, whether concurrent or not. Consider the two following scenarios, both of which cause file fragmentation.

In scenario 1, two users are creating files at the same time. If two users request the creation of files at the same time, the file system must synchronize these events to happen one at a time. In this case, let's assume user 1's request is honored first. Some disk blocks are allocated to the file (the initial allocation) in anticipation of the user's writing data to it. However, the file system must not indefinitely stall user 2's request. When the creation ^[1] of the first file is finished, the file system will create file 2 and allocate some blocks for it. As both users write data to their respective files, their initial allocations will eventually be filled.

At this point, file 1 must be extended, but the initial allocation of file 2 occupies the next logical blocks on the volume. The next part of file 1 must be placed at some other location. Thus, file 1 becomes fragmented.

Figure 20-1: File Fragmentation

In scenario 2, a single user is writing multiple files. It is easy to envision how a single user creating two or more files at once can create fragmented files in exactly the same way as two users creating one file each.

In addition, the file system must work around portions of files already existing on the disk and eventually use free space that becomes available as files are deleted. At any given time, there may not be a single range of free blocks large enough to hold the data to be written, or, frequently, a file may be opened without the system knowing how much data will be written to it. In this fashion, files on the disk will become fragmented.

^[1]The term creation refers only to allocating a header, a directory entry, and the initial blocks of a file; no data have yet been placed into the file.