Tune the Linux Ext4 file system for optimal performance
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.