![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Linux supports several different file systems. Some are specialized network
file systems or file systems developed for other operating systems, but a
surprising number may be used as Linux native file systems—you can place your
Linux root (/) and system directories on such file
systems. Currently, file systems in this category include ext2, ext3, ReiserFS,
XFS, and Journaled File System (JFS). However, file system design and development
are ongoing, and new file systems are on the horizon.
Perhaps the most important file system currently under development for Linux is ext4—the fourth incarnation of the original extended file system (ext or extfs) developed exclusively for Linux. Given its heritage, it seems likely that ext4 will become an important standard file system (perhaps the standard file system) for Linux in the not-too-distant future.
The fourth extended file system (ext4 or ext4fs) exists because developers were pushing to incorporate new and advanced features into ext3. This drive presented several problems:
- Some of the new features would break backwards compatibility.
- The ext3 code would become more complex and difficult to maintain.
- The changes might cause the highly reliable ext3 to become unreliable.
For these reasons, the developers decided to fork ext4 development off of ext3 in June of 2006. Since that time, ext4 development has proceeded, largely unnoticed by mere mortal Linux users and administrators. With the release of the 2.6.19 kernel in November of 2006, ext4 made its first appearance in a mainstream kernel, although it was (and still is) marked as experimental, so most people have ignored it.
Because ext4 is still under development, as of the 2.6.24.4 kernel, its feature list is in flux. Current and anticipated features include the advancements over ext3 listed in Table 1.
Table 1. Current and upcoming features of ext4 that provide advantages over ext3
| Feature | Advantage |
|---|---|
| Larger file systems | Ext3 tops out at 32 tebibyte (TiB) file systems and 2 TiB files, but practical limits may be lower than this depending on your architecture and system settings—perhaps as low as 2 TiB file systems and 16 gibibyte (GiB) files. Ext4, by contrast, permits file systems of up to 1024 pebibyte (PiB), or 1 exbibyte (EiB), and files of up to 16 TiB. This may not be important (yet!) for the average desktop computer or server, but it is important to users with large disk arrays. |
| Extents | An extent is a way to improve the efficiency of on-disk file descriptors, reducing deletion times for large files, among other things. |
| Persistent preallocation | If an application needs to allocate disk space before actually using it, most file systems do so by writing 0s to the not-yet-used disk space. Ext4 permits preallocation without doing this, which can improve the performance of some database and multimedia tools. |
| Delayed allocation | Ext4 can delay allocating disk space until the last moment, which can improve performance. |
| More subdirectories | If you've ever felt constrained by the fact that a directory can only hold 32,000 subdirectories in ext3, you'll be relieved to know that this limit has been eliminated in ext4. |
| Journal checksums | Ext4 adds a checksum to the journal data, which improves reliability and performance. |
| Online defragmentation | Although ext3 isn't prone to excessive fragmentation, files stored on it are likely to become at least a little fragmented. Ext4 adds support for online defragmentation, which should improve overall performance. |
| Undelete | Although it hasn't been implemented yet, ext4 may support undelete, which, of course, is handy whenever somebody accidentally deletes a file. |
| Faster file system checks | Ext4 adds data structures that permit fsck to
skip unused parts of the disk in its checks, thus speeding up file system
checks. |
| Nanosecond timestamps | Most file systems, including ext3, include timestamp data that is accurate to a second. Ext4 extends the accuracy of this data to a nanosecond. Some sources also indicate that the ext4 timestamps support dates through April 25, 2514, versus January 18, 2038, for ext3. |
As ext4 is currently a work in progress, this feature list is subject to change. Some of these features, if used, create backwards incompatibility with ext3—that is, you may not be able to mount an ext4 file system using the ext3 file system type code. Ext4 does maintain forwards compatibility, though—you should be able to mount an ext3 file system as if it were an ext4 file system.
The single most dramatic improvement in ext4 is in file and file system size. Thus, the users who are most likely to need ext4 are those who have more than a few terabytes of disk space. The list of features in Table 1, though, may present some other tempting improvements. For instance, you might want to try ext4 if you have directories with huge numbers of subdirectories or if you need timestamps accurate to less than a second.
Because ext4 is currently experimental, to use it you'll almost certainly have to recompile your kernel. If you're uncomfortable with this task, chances are you'll have trouble with ext4. In fact, the experimental nature of ext4 means that you really should use it only if you're interested in contributing to its development or if you're desperate for some of its features. If you need reliable large-disk support prior to a stable release of ext4, you might want to consider using XFS or JFS instead.
Of course, ext4 won't always be experimental. In time, ext4 will be declared a stable file system. When this happens, ext4 will be as good a choice as ext3 for just about everybody, with a couple of caveats. First, it's conceivable that bugs unique to ext4 will exist, so you should be wary when ext4 is first declared stable. Second, using ext4 may make it impossible for older tools to access your disk. This will have implications for emergency recovery tools, so you may want to wait for your preferred tools to support ext4 before you upgrade. On the plus side, it should be possible to migrate from ext3 to ext4 non-destructively, which will enable an easy transition if you have existing data you want to preserve.
Compiling and activating ext4 support
If you've read this far, you're presumably willing to experiment with ext4. To do
so, you need to recompile your kernel to add the necessary support. I recommend
you start with the newest available kernel (which is 2.6.24.4 as I write). After
unpacking the kernel source and either manually setting all the options or copying
an older kernel's .config file and typing
make oldconfig to copy over your old settings, type
your preferred configuration command (such as
make xconfig) to view the kernel options. You'll find
the ext4 option in the main File Systems area, as Ext4dev/ext4 extended
fs support development (EXPERIMENTAL). (The name is likely to change in the
future, particularly when ext4 is declared stable.) Note that you must check the
Prompt for development and/or incomplete code/drivers option in the
General area to even see the ext4 option.
With ext4 support selected, save your kernel changes, compile the kernel by
typing make, and install the modules by typing
make modules_install as
root. You then need to copy the compiled kernel (in
arch/i386/boot or some other directory) to an
appropriate location (such as /boot), edit your GRand
Unified Bootloader (GRUB) or Linux Loader (LILO) configuration, and reboot your
computer. If you use a boot RAM disk, you need to prepare it with the
mkinitrd utility, as well.
In addition to the kernel module, you may want to look at a version of
e2fsprogs that supports the ext4 file system features.
You can either download a tarball (the Resources section
points you to the appropriate site) or use git, as
demonstrated in Listing 1.
Listing 1. Commands to retrieve the latest
e2fsprogs via git$ git clone git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git $ cd e2fsprogs $ git checkout -b pu Switched to a new branch "pu" $ git branch master * pu $ git pull git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git pu |
Note that you may need to install git using your
distribution's package manager. These tools do not yet get a lot of testing, so
they aren't recommended for use on production systems, and, at the moment, they
don't seem to add a lot that's really necessary for ext4 use. Thus, you may prefer
to stick with the stock e2fsprogs package delivered
with your distribution.
The compilation process for e2fsprogs is fairly
standard: Uncompress the package, cd into the resulting
directory, type ./configure, type
make, and (as root) type
make install. This process will overwrite your
distribution's normal e2fsprogs package, so do it
only if you're sure you want to use the latest (and possibly unstable) version of
these tools.
With your system booted into a kernel with ext4 support, you're ready to begin using the new file system. To do so, you need to prepare a partition, redundant array of independent disks (RAID) device, or other storage space. You can then begin using it as an ext4 file system and tweak file system options.
If you want to make a clean start, you can format a partition or other device
using the tools provided with the old or new e2fsprogs
package, namely mkfs.ext3 or
mkfs.ext4. For instance,
mkfs.ext4 -j /dev/sda6 prepares the
/dev/sda6 partition for use. Using
mkfs.ext4 may produce a file system with more
ext4-specific features activated.
Presently, the e2fsprogs programs are not fully
up-to-date with the kernel file system changes. Fortunately, most of the kernel
driver features don't require special preparation from
mkfs.ext4 or other utilities. The ext4 features are
activated when you mount the file system. If you want to use ext4 on large media,
you'll be going boldly where few have gone before, so be sure to document and
report any problems you encounter!
If you want to use an existing ext2 or ext3 file system as an ext4 file system, you may do so. Simply mount the device as described shortly. If you use certain new features, though, such as extents, you won't be able to go back to using the file system with the ext2 or ext3 drivers.
To use a device as an ext4 file system, you should mount it with the
ext4dev file system type code. (When ext4 becomes
stable, the file system type code will change to ext4.)
For instance, mount -t ext4dev /dev/sda6 /mnt/point
mounts /dev/sda6 as an ext4 file system at
/mnt/point. That's all there is to basic ext4 use. Be
aware that the default mount options enable extents, which renders the file system
unusable as an ext3 file system. If you want to try ext4 but retain the option of
going back to ext3, use the -o noextents option to
disable use of extents.
Practical use of ext4, once mounted, is just like that of any other file system: you can copy files, create them directly, and so on. Unless you run into a bug or perform benchmark tests, you shouldn't notice any differences.
Tweaking ext4 performance options
You can use the tune2fs program to tune an ext4 file
system in the same ways you'd tune an ext2 or ext3 file system. At present,
tune2fs doesn't provide any ext4-specific options,
although you can set ext4 options, such as extents,
using the standard -O parameter.
When you mount a file system as ext4, the kernel begins using file system-specific features, such as extents. This makes it impossible to mount the file system again as an ext3 file system, at least not without jumping through quite a few hoops.
Although mounting an ext3 file system as ext4 enables the ext4-specific features,
mounting alone doesn't convert old data structures to the new formats. For
instance, existing files remain allocated block-for-block, rather than using
extents. Thus, your old files don't gain the benefit of the new features. The ext4
developers have considered this fact, however, and provided a way forward: You can
use the (very experimental) e4defrag tool
(described shortly) to convert allocations to use extents. Another new tool (which
isn't yet available) will change inode sizes to the new format.
Maintaining an ext4 file system
You can use the standard e2fsprogs tool to maintain an
ext4 file system, such as tune2fs to adjust options
after creating the file system, fsck.ext4 to perform a
file system check, and so on. These programs aren't much different for ext4
compared to ext3. Although, as noted earlier, ext4 includes some enhancements that
should improve the performance of fsck.
In addition to these tools, a new one deserves special mention:
e4defrag. This program defragments a mounted ext4 file
system. This can improve performance, particularly if your file system has become
close to full. It also has the advantage of converting ext2/3-style allocation to
the ext4-style extents-based allocation, so it can improve performance on a file
system that had previously been used as an ext3 file system. Unfortunately,
e4defrag isn't yet part of the standard
e2fsprogs package, so you need to dig up a "bare" copy
(the Resources section provides a link).
Learn
-
See the main
ext4 wiki as well as the ext4 Howto on Wikipedia for
additional information and links.
-
In the
developerWorks Linux zone,
find more resources for Linux developers, and scan our
most popular articles and
tutorials.
-
See all
Linux tips and
Linux tutorials on developerWorks.
-
Stay current with
developerWorks technical events and Webcasts.
Get products and technologies
-
Get
e2fsprogswith ext4 support from ftp.kernel.org. -
Find a copy
of the source code for the
ext4defrag
utility, even though it is not yet
part of the main
e2fsprogspackage. -
With
IBM trial software,
available for download directly from developerWorks, build your next development
project on Linux.
Discuss
-
Get involved in the
developerWorks community through blogs, forums, podcasts, and community topics in our
new developerWorks spaces.
