Manage Learn to apply best practices and optimize your operations.

Tune the Linux Ext4 file system for optimal performance

While Ext4 by default works fine for most people, follow these tips to tweak your servers to squeeze out even more speed.

In normal Ext4 file system creation, default settings are used. These work well for default workloads. But if your...

server shows a non-average performance pattern, you may benefit from tuning the performance of the Ext4 file system. In this article, see how to push Ext4 to the max.

Survey your system
Optimizing an Ext4 file system isn’t limited to adjusting the file system. The first step is to make sure the host server can handle a fast file system, begin by assigning a large enough amount of RAM. A well-tuned file system low on RAM can’t offer optimal performance because there isn’t enough space to properly cache the file system metadata tables.

To find out if your server has enough RAM, use the free command. If the total memory used in buffers and cache is above 20% of the total amount of RAM, it will work. But more is better. Ideally you need about 40% of server RAM available for buffers and cache.

Next, check your disks. For the best possible performance, you'll need the best possible disks. That doesn’t mean you need only SSD disks. But don't use 7,200 RPM SATA if you need speed — use 15,000 RPM serial-attached SCSI (SAS) instead.

Also take the disk controller parameters into consideration. Make sure the battery-backed cache is enabled. Configure writes to be delayed to increase write performance. If you prefer read performance, configure read-ahead to increase the chances the data you need next is already loaded in RAM when you need it.

Optimizing the Ext4 file system
Now that the servers are checked, let’s optimize the Ext4 file system. There are two items you should always consider, and then you may check more specific performance parameters.

One parameter that helps in nearly all situations is to disable file system access time — use the noatime mount option in /etc/fstab. Without this option, every time a file is accessed (including reads), the metadata of the file is changed. Most servers don't do anything with that information, so switch it off.

Another interesting mount option is the dealloc option, which switches on the deferred block allocation feature. This feature decides which blocks to use when writing a file occur at the very last moment, optimizing the write process.

 Another rather important mount option tunes the file system journal. There are three journaling modes: data=journal, data=ordered and data=writeback. The default setting data=ordered offers the best balance between performance and protection. But if your server needs to write large amounts of data, it can freeze your server for a long period. If this is the case, using utilities like iotop, you will see a high load for the kjournald process. If your server suffers from this behavior, use the data=writeback option for better write performance. But using this option increases risks that recently modified data will be corrupted during a crash.

There are a few options that can be used while creating the file system to get better performance. The first is the inode size. The inode is used to store metadata, and if extended attributes or access control lists (ACLs) are used on a file system, the default inode is not big enough to store all data and a secondary inode is allocated. That means that for all file access you'll need two operations instead of one. Use mkfs with the -I 256 option, to set the inode size to 256 instead of 128. Turning off User Extended Attributes and ACLs completely is not a good idea, as you need them to use Ext4 extents.

While the Ext4 file system by default is optimized very well, tuning your file system may come down to creating the ideal server hardware configuration. The noatime mount option provides performance advantages in most situations. Optimization then depends on what your server is doing. Most servers that suffer from bad file system performance have problems writing data in an efficient way.

ABOUT THE AUTHOR: Sander van Vugt is an independent trainer and consultant living in the Netherlands. Van Vugt is an expert in Linux high availability, virtualization and performance and has completed several projects that implement all three. Sander is also a regular speaker on many Linux conferences all over the world. He is also the writer of various Linux-related books, such as Beginning the Linux Command LineBeginning Ubuntu Server Administration and Pro Ubuntu Server Administration.

This was last published in February 2012

Dig Deeper on Linux servers



Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

The suggestion to delay allocations is counter-indicated by research. Large files, can have dramatically improved performance if the fs is allowed to allocate large blocks early. Compared to previous file systems, not only is fragmentation reduced, but the physical layout is more regularized along addressing modes. While many linux pages claim that delayed allocation improves fragmentation, as is often the case, this general statement does not hold true for edge cases; very large files. In the big-data world,which is next door to enterprise and search, the performance of application specific scenarios is more important that building a "generally well tuned" system for beginners to play with.