Selecting a file system for a database

If possible, it is best to use the log file system, EXT3,EXT4,XFS,ZFS or JFS. If you do not, the file system check may take a long time after the crash, and if the system is not important, the non-log file system may be better than the support transaction, for example, ext2 may work better than ext3, or you can use Tunefs to turn off ext3 logging. Hanging on time for some file systems is also a factor, for example, ReiserFS, on a large partition may take a long time to hang on and perform log recovery.

Regardless of the file system, there are some specific options are best disabled, because they do not provide any benefits, but add a lot of overhead, the most famous is the option to record access time, even read the file or directory when a write operation, in/etc/fstab add Noatime, Nodiratime hangs on the option to disable this option, which can sometimes improve the performance of 5%-%10. Specific decisions are made on the workload and the file system. Here is an example of/etc/fstab, which sets the line for the EXT3 option:

/dev/sda2/usr/lib/mysql ext3 noatime,nodiratime,data=writeback 0 1

You can also use the read-ahead behavior of the file system, which may be superfluous, for example, InnoDB has its own read-ahead policy, so the pre-read of the filesystem is redundant, disabling or restricting pre-reading is especially advantageous for Slorias UFS, and using the O_direct option disables pre-reading automatically.

We recommend using the XFS file system, there are too many serious restrictions on the Ext3 file system (what limits?). For example, the inode has only one mutex (how to understand it), and Fsync () flushes all the dirty blocks (how do you know, is it refreshing all the dirty blocks on the filesystem?). What about the file system's dirty chunks, and not the individual files?