Ext3 and Ext3 can be briefly characterized as follows:

□ The Second Extended Filesystem — This has been with Linux from the early days and has proved itself as the backbone of many server and desktop systems, where it has done a very good job. The design of the Ext2 filesystem makes use of structures very similar to those used in the virtual filesystem, simply because it was developed with optimized interoperation with Linux in mind. It can be — and is — used with other operating systems, though.

□ The Third Extended Filesystem — This is an evolutionary development of Ext2. It is still mostly compatible with Ext2, but provides an extension — journaling — that is especially helpful to recover from system crashes. This chapter 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 storage and may even make the situation worse. Wasteful use of disk capacity should also be avoided — the advantages of less management data are lost because space is not used efficiently. The various filesystem implementations address this problem differently. Often, administrator-configured parameters are introduced 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 unexpectedly, not only because of software errors, but also 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.

Continue reading here: Second Extended Filesystem

Was this article helpful?

0 0