Choosing and tuning your filesystem
Choosing the best filesystem for a specific system is very important because each has its own strengths. The beginner’s guide provides a short summary of the most popular ones. You can also find relevant articles here.
Summary of different type of file-systems
- XFS: Excellent performance with large files. Low speed with small files. A good choice for /home.
- Reiserfs: Excellent performance with small files. A good choice for /var.
- Ext3: Average performance, reliable.
- Ext4: Great overall performance, reliable, has performance issues with sqlite and some other databases.
- JFS: Good overall performance, very low CPU usage.
- Btrfs: Great overall performance (better than ext4), reliable (once it becomes stable). Lots of features. Still in heavy development and considered as unstable. Do not use this filesystem yet unless you know what you are doing and are prepared for potential data loss. But some reviews test does not show the performance of Btrfs file-systems better at all.
I recommand use The ext4 or fourth extended filesystem is a journaling file-system for Linux, because I was used the ext4 file-system to describe “How to speed-up the file-systems” in this article.
Mount options
Mount options offer an easy way to improve speed without reformatting. Some articles boosted rails test suite running time by around 30% by adding certain mount options for their ext4 partition (works for ext3 too). They can be set using the mount command:
$ mount -o option1,option2 /dev/partition /mnt/partition
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:
/dev/partition /mnt/partition partitiontype option1,option2 0 0
For example:
A couple of mount options improving performance on almost all file-systems is noatime,nodiratime. The former is a superset of the latter (which applies to directories only — noatime applies to both files and directories). In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the relatime option.
/dev/sda3/ /home ext4 noatime,data=writeback,barrier=0,nobh,errors=remount-ro 0 0The main ones are replacing atime/relatime with noatime. This causes the file-systems to not write read-times to a file when read. Think about it. Writing to the file-systems for every read of the file-systems?
After, run the command to turn-on the writeback function.
tune2fs -o journal_data_writeback /dev/sda3
Journaling options and write latency
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). In below I explain more mount option with data that can improve both the performance and the reliability of the filesystem.
Ext3 , Ext4 , etc. journaling file-systems has three kinds of journaling methods:
1) Journal Data Writeback (data=writeback)In data=writeback mode, ext3 doesn’t do any form of data journaling at all, providing you with similar journaling found in the XFS, JFS, and ReiserFS filesystems (metadata only).
Seriously!!! This could allow recently modified files to become corrupted in the event of an unexpected reboot.
2) Journal Data Ordered (
data=ordered)In data=ordered mode, ext3 only officially journals metadata, but it logically groups metadata and data blocks into a single unit called a transaction. When it’s time to write the new metadata out to disk, the associated data blocks are written first. data=ordered mode effectively solves the corruption problem found in data=writeback mode and most other journaled filesystems, and it does so without requiring full data journaling. In general, data=ordered ext3 filesystems perform slightly slower than data=writeback filesystems, but significantly faster than their full data journaling counterparts.
When appending data to files, data=ordered mode provides all of the integrity guarantees offered by ext3′s full data journaling mode. However, if part of a file is being overwritten and the system crashes, it’s possible that the region being written will contain a combination of original blocks interspersed with updated blocks. This is because data=ordered provides no guarantees as to which blocks are overwritten first, so you can’t assume that just because overwritten block x was updated, that overwritten block x-1 was updated as well. Instead, data=ordered leaves the write ordering up to the hard drive’s write cache. In general, this limitation doesn’t end up negatively impacting people very often, since file appends are generally much more common than file overwrites. For this reason, data=ordered mode is a good higher-performance replacement for full data journaling.
3) Journal Data (
data=journal)data=journal mode provides full data and metadata journaling. All new data is written to the journal first, and then to its final location. In the event of a crash, the journal can be replayed, bringing both data and metadata into a consistent state.
Theoretically, data=journal mode is the slowest journaling mode of all, since data gets written to disk twice rather than once. However, it turns out that in certain situations, data=journal mode can be blazingly fast. Andrew Morton, after hearing reports on LKML that ext3 data=journal filesystems were giving people unbelievably great interactive filesystem performance, decided to put together a little test.
barrier Which is slightly more dangerous:
Since kernel 2.6.30, ext4 performance has decreased due to changes that serve to improve data integrity. Users can improve performance with the nobarrier option when mounting the disk, but this can be dangerous and may result in data loss or corruption after power failures. To turn barriers off, add the option barrier=0 to the desired filesystem in /etc/fstab.
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.
nobh (Anyone have any details about the nobh function?)
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).
Sources & References :
http://wiki.archlinux.org/index.php/Maximizing_Performance#Choosing_and_tuning_your_filesystem ;
http://www.gentoo.org/doc/en/articles/l-afig-p8.xml?style=printable ;
http://wiki.ubuntu-tw.org/index.php?title=Ubuntu_%E9%80%B2%E9%9A%8E%E5%84%AA%E5%8C%96%E5%92%8C%E8%AA%BF%E6%A0%A1 ;
http://ubuntuforums.org/showthread.php?t=107856 ;
http://blog.smartlogicsolutions.com/2009/06/04/mount-options-to-improve-ext4-file-system-performance/ ;
http://mkl-note.blogspot.com/2008/05/howto-tweak-your-ext3-filesystem-for.html ;
http://wiki.centos.org/zh-tw/HowTos/Disk_Optimization