Tip

Tune the Linux Ext4 file system for optimal performance

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

    Requires Free Membership to View

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 first published in February 2012

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
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
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.