Why ext3?
A list of reasons why Red Hat chose ext3 for our first officially supported
journaling file system follows. Note that these reasons are not necessarily
each unique to ext3 (some other journaling file systems share several of the
points here), but the whole set of reasons taken together is unique to ext3.
- ext3 is forward and backward compatible with ext2, allowing users
to keep existing file systems while very simply adding journaling
capability. Any user who wishes to un-journal a file system can do so
easily (not that we expect many to do so...). Furthermore, an ext3 file
system can be mounted as ext2 without even removing the journal, as long as
a recent version of e2fsprogs (such as the one
included in Red Hat Linux 7.2) is installed.
- ext3 benefits from the long history of fixes and enhancements to
the ext2 file system, and will continue to do so. This means that ext3
shares ext2's well-known robustness, but also that as new features are added
to ext2, they can be carried over to ext3 with little difficulty. When, for
example, extended attributes or HTrees are added to ext2, it will be
relatively easy to add them to ext3. (The extended attributes feature will
enable things like access control lists; HTrees
make directory operations extremely fast and highly scalable to very large
directories.)
- ext3, like ext2, has a multi-vendor team of developers who develop
it and understand it well; its development does not depend on any one person
or organization.
- ext3 provides and makes use of a generic journaling layer (jbd)
which can be used in other contexts. ext3 can journal not only within the
file system, but also to other devices, so as NVRAM devices become available
and supported under Linux, ext3 will be able to support them.
- ext3 has multiple journaling modes. It can journal all file data
and metadata (data=journal), or it can journal metadata but
not file data (data=ordered or
data=writeback). When not journaling file data, you can
choose to write file system data before metadata
(data=ordered; causes all metadata to point to valid data),
or not to handle file data specially at all
(data=writeback; file system will be consistent, but old
data may appear in files after an unclean system shutdown). This gives the
administrator the power to make the trade off between speed and file data
consistency, and to tune speed for specialized usage patterns.
- ext3 has broad cross-platform compatibility, working on 32- and
64- bit architectures, and on both little-endian and big-endian systems.
Any system (currently including many Unix clones and variants, BeOS, and
Windows) capable of accessing files on an ext2 file system will also be able
to access files on an ext3 file system.
- ext3 does not require extensive core kernel changes and requires
no new system calls, thus presenting Linus Torvalds no challenges that would
effecitvely prevent him from integrating ext3 into his official Linux kernel
releases. ext3 is already integrated into Alan Cox's -ac
kernels, slated for migration to Linus's official kernel soon.
- The e2fsck file system recovery program has a long and proven
track record of successful data recovery when software or hardware faults
corrupt a file system. ext3 uses this same e2fsck code for salvaging the
file system after such corruption, and therefore it has the same robustness
against catastrophic data loss as ext2 in the presence of data-corruption
faults.
Again, we do not claim that each one of these points is unique to ext3. Most of
them are shared by at least one other file system. We merely claim that the set
of all of them together is true only for ext3. The expressed needs of our
customers drove our decisions about what feature set was important for us to
support right now. In our judgement, ext3 currently has the best fit for our
customers' requirements. We will continue to evaluate other file systems for
inclusion in future versions of Red Hat Linux.
|
