Chapter 9: The Extended Filesystem Family
Chapter 9: The Extended Filesystem Family.................................
helpful to recover from system crashes. Thischapter also takes a brief look at the journal
mechanism of Ext3. As compared with Ext2, this features several interesting options, but
the basic filesystem principles are unchanged.While most installations nowadays prefer Ext3 to Ext2, it nevertheless makes sense to discuss Ext2 first:
Since the code need not implement any journaling functionalities, it is often simpler as compared to the
Ext3 implementation, and thus makes the essential principles easier to understand. Besides journaling,
both variants are otherwise nearly completely identical, and many general improvements that originate
from Ext3 have been back-ported to Ext2.One specific problem — fragmentation — is encountered in the management of storage space for disk-
based filesystems. Available space becomes more and more fragmented as files are removed and new
ones are added — particularly if the files are very small. Because this has a negative impact on access
speed, filesystems must try to keep fragmentation to a minimum.A second important requirement is to put storage space to efficient use, and here the filesystem must
make a compromise. Full use of space can only be achieved at the cost of large amounts of management
data that must also be stored on disk. This cancels out any benefit gained from more compact data stor-
age and may even make the situation worse. Wasteful use of disk capacity should also be avoided — the
advantages of less management data are lost becausespace is not used efficiently. The various filesystem
implementations address this problem differently. Often, administrator-configured parameters are intro-
duced to optimize the filesystem for anticipated usage patterns (e.g., a predominantly large number of
big files or small files).Maintaining the consistency of file contents is also a key issue that requires careful thought during the
planning and implementation of filesystems. Even the most stable of kernels can give up the ghost unex-
pectedly, not only because of software errors, butalso owing to power outages, hardware faults, and
the like. Even if mishaps of this kind cause irrecoverable errors (e.g., changes are lost if they are still
cached in RAM and have not been written back to disk), the implementation must make every effort to
rectify damage as quickly and as comprehensively as possible. At minimum, it must be able to restore
the filesystem to a usable state.Finally, speed is also a vital ingredient when assessing the quality of filesystems. Even if hard disks are
extremely slow as compared to the CPU or RAM, a badly implemented filesystem can certainly apply
the brakes to system speed.9.2 Second Extended Filesystem
Even though Linux is neither a clone nor a further development of the educational Minix, many parts
of the early Linux kernel (and ‘‘early’’ by now means roughly a decade ago!) clearly reflected its Minix
heritage. The first filesystem the Linux kernel had to deal with was a direct adaptation of the Minix
system. This had primarily practical reasons because Linux was originally developed on a Minix system
before it was capable of hosting itself. We have come a long way since then.The code of the Minix filesystem may have been valuable in educational terms, but it left a lot to be
desired in terms of performance.^1 Many standard features of commercialUnixsystems were simply(^1) Note that the situation has changed somewhat with with the introduction of Minix 3, which has explicitly been designed to be
usable on embedded devices and similar systems with little computing power. Most people, however, still seem to prefer embedded
Linux distributions for these purposes.