Ruby on Rails: Mount options to improve ext4 file system performance

I recently boosted my rails test suite running time by around 30% by adding certain mount options for my ext4 partition (works for ext3 too). I thought I'd blog about it because the first time I tried my system wouldn't boot! So here are the step by step instructions:

2) Run:
> tune2fs -o journal_data_writeback /dev/sdXY
Where /dev/sdXY is replaced by the partition that you want to boost

4) Edit fstab

> nano -w /mnt/sdXY/etc/fstab

Find the line that references sdXY. It will look something like:

# /dev/sda2 UUID=be2f0ac2-4683-4550-bcd1-704a1a840b3e / ext4 relatime,errors=remount-ro 0 1

The first entry is the UUID (although on your system this could just be /dev/sdXY). The second entry is the path (/ for me). Third is the fstype (ext3/4). Fourth are the options. Fifth is for dump and sixth is pass. See man fstab(5) for more info.

Change the options to:


(you can leave all of yours in place, if they weren't the same as mine.

The main ones are replacing atime/relatime with noatime. This causes the FS to not write read-times to a file when read. Think about it. Writing to the FS for every read of the FS? crazy!

Next is data=writeback. This means that metadata for files can be written lazily after the file is written. This will not cause file system corruption, but it may cause the most recent changes to be lost in the event of a crash (so you may jump back into the past a bit).

Next is barrier, which is slightly more dangerous:

barrier= This enables/disables the use of write barriers in
the jbd code. barrier=0 disables, barrier=1 enables.
This also requires an IO stack which can support
barriers, and if jbd gets an error on a barrier
write, it will disable again with a warning.
Write barriers enforce proper on-disk ordering
of journal commits, making volatile disk write caches
safe to use, at some performance penalty. If
your disks are battery-backed in one way or another,
disabling barriers may safely improve performance.

Next is nobh:

bh (*) ext4 associates buffer heads to data pages to
nobh (a) cache disk block mapping information
(b) link pages into transaction to provide
ordering guarantees.
"bh" option forces use of buffer heads.
"nobh" option tries to avoid associating buffer
heads (supported only for "writeback" mode).

You can skip barrier and nobh if you'd like. noatime and data=writeback are the big ones.

6) Reboot to your system.

If you have any trouble booting, just boot a recovery disk and revert the fstab changes.

EDIT: Updated to no longer require recovery disk booting thanks to Nicolas Alpi's response post.

Want more tips on rails development, check out some of our other articles:

Rails Development: Naming Conflicts on a Polymorphic has_many

Ruby on Rails: Using RSpec Macros and MetaData

comments powered by Disqus