Many of the mainstream Linux distributions are shipping with full ext4 file system support, so it's time to look at what ext4 brings to the table for upgrade and implementation decisions.
All the major Linux distributions released since 2008 have included support for ext4 volumes.
Ext4 was released with support of very large files (up to 16 TB) and extremely large volumes
(supports file system size of 1,048,576 TB) in mind. It includes support for in-place upgrades,
meaning you can run a few commands (
e2fsck) and convert an
existing ext2 or ext3 volume over to ext4. This capability was deemed as necessary to allow for the
conversion of very large volumes without the need to first back them up, but backing them up is
always a good idea.
Using an ext4 compatible bootloader
Every time you power up a computer you go through a boot process involving first the BIOS and typically the boot sector on a hard disk. For Linux systems the next step in the process involves either LILO (LInux LOader) or GRUB (GRand Unified Bootloader). Most current Linux distributions use some version of GRUB. GRUB 2 includes support for ext4 boot partitions. This is helpful because it prevents you from having two different file systems running for the boot partition and everything else. Standardizing on one file system simplifies things, and keeps you from splitting a single hard drive into multiple partitions. Again, not a show-stopper, but multiple partitions on a single disk spindle could adversely affect performance.
The most recent release of Fedora includes direct support for ext4 on the boot partition through the use of an updated GRUB. Ubuntu 9.10 also supports ext4 on the boot partition but requires you to run the grub-install command after an in-place upgrade (see the Ubuntu 9.10 release notes). You should be aware that if you don't run the grub-install you will find yourself with an unusable system.
There have been a few benchmarks that seem to indicate a potential drop in system performance using ext4 in some situations (like PostgreSQL and Linux kernels after 2.6.31). This was attributed to additional work being done at the kernel level to further improve the overall file system reliability. It is important to understand what types of tests a particular benchmark uses to determine performance and to look at the results with an eye toward your specific requirements. Numbers of files, file sizes and applications (like heavy database versus serving Web content) will vary wildly in the real world compared to a canned test.
It's also important to understand some of the new features of ext4 to help make an informed decision about upgrading. Journal checksumming is a new feature to ext4 and helps to ensure the integrity of the disk area used when performing journaling process. This makes it possible to determine if journal blocks are causing errors that could corrupt the file commit process. Additionally, this process is now a single phase event with up to 20% performance improvement in filesystem operations. You can also turn journaling off if you don't need the extra reliability and need the performance gain. Barriers are another reliability feature that can be turned off to improve performance, but you run the risk of potential data corruption should your disk not be able to handle the amount of data.
One of the areas where ext4 really shines versus previous versions is when running
fsck (file system check). In ext3 and earlier, fsck had to traverse large numbers of
inodes to determine if the file system was corrupt or not. With ext4, it is possible to skip over
inodes that are known to be empty. Performance improvements by over 100% have been seen in some ext4 benchmarks
performed for the Linux Foundation.
File system decisions
Migrating existing Linux volumes to ext4 should be evaluated on a case-by-case basis. If you need the support for large files (> 2TB), filesystem (> 16 TB) or numbers of sub directories (ext3 is limited to 32000) you'll definitely want to upgrade. For new installations it probably makes sense to go with ext4. Existing production systems that aren't in any danger of exceeding any of the size limits might want to hold off.
For more information on ext4, check out this overview of the extended (ext) file system from IBM Developerworks, including a short introduction on the history of Linux file systems. Make sure you scroll to the end for a great list of ext4 resources.
ABOUT THE AUTHOR: Paul Ferrill has a BS and MS in electrical engineering and has been
writing about computers for over twenty years. He's had articles published in PC Magazine, PC
Computing, InfoWorld, Computer World, Network World, Network Computing, Federal Computer Week,
Information Week, and multiple Web sites.
This was first published in February 2010