Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I tried to look for benchmark on the performances of various filesystems with MySQL InnoDB but couldn't find any.

My database workload is the typical web-based OLTP, about 90% read, 10% write. Random IO.

Among popular filesystems such as ext3, ext4, xfs, jfs, Reiserfs, Reiser4, etc. which one do you think is the best for MySQL?

share|improve this question

7 Answers 7

up vote 36 down vote accepted

How much do you value the data?

Seriously, each filesystem has its own tradeoffs. Before I go much further, I am a big fan of XFS and Reiser both, although I often run Ext3. So there isn't a real filesystem bias at work here, just letting you know...

If the filesystem is little more than a container for you, then go with whatever provides you with the best access times.

If the data is of any significant value, you will want to avoid XFS. Why? Because if it can't recover a portion of a file that is journaled it will zero out the blocks. As in, kiss your data goodbye. This is perfectly acceptable when you are working with multi-gigabyte digital video streams, and you were compositing a stream before the crash - you simply restart the process and presto! the data is there again. And you really don't want to wait around to fsck terabytes of video data, do you?

In a database environment, it's a recipe for disaster. Can you say "restore from backup"?

ReiserFS is a great filesystem, provided that it never crashes hard. The journal recovery works fine, but if for some reason you loose your parition info, or the core blocks of the filesystem are blown away, you may have a quandry if there are multiple ReiserFS partitions on a disk - because the recovery mechanism basically scans the entire disk, sector by sector, looking for what it "thinks" is the start of the filesystem. If you have three partitions with ReiserFS but only one is blown, you can imagine the chaos this will cause as the recovery process stitches together a Frankenstein mess from the other two systems...

Ext3 is "slow", in a "I have 32,000 files and it takes time to find them all running ls" kinda way. If you're going to have thousands of small temporary tables everywhere, you will have a wee bit of grief. Newer versions now include an index option that dramatically cuts down the directory traversal but it can still be painful.

I've never used JFS. I can only comment that every review of it I've ever read has been something along the lines of "solid, but not the fastest kid on the block". It may merit investigation.

Enough of the Cons, let's look at the Pros:

XFS:

  • screams with enormous files, fast recovery time
  • very fast directory search
  • Primitives for freezing and unfreezing the filesystem for dumping

ReiserFS:

  • Highly optimal small-file access
  • Packs several small files into same blocks, conserving filesystem space
  • fast recovery, rivals XFS recovery times

Ext3:

  • Tried and true, based on well-tested Ext2 code
  • Lots of tools around to work with it
  • Can be re-mounted as Ext2 in a pinch for recovery
  • Can be both shrunk and expanded (other filesystems can only be expanded)
  • Newest versions can be expanded "live" (if you're that daring)

So you see, each has its own quirks. The question is, which is the least quirky for you?

share|improve this answer
25  
That XFS NULLed files issue was fixed over 3 years ago. xfs.org/index.php/… –  EvilRyry Apr 26 '10 at 18:28
2  
While it's true that I don't have all the time in the world to keep up with kernel development changes (on top of work and a family), it's also certainly true that there are creaky old deployments out there that need updating. However, I'll chip in a +1 for pointing out the fix was made. –  Avery Payne Apr 27 '10 at 17:02

The answers here are seriously deprecated, and need updating as this is coming up in google results.

For produciton environments, XFS. Everytime. XFS is journaled and non-blocking. Make sure you have the following variables for a modern (2011/2012) MySQL database using InnoDB in production:

innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1 # an ACID requirement
sync_binlog = 1 # more ACID
innodb_flush_method = O_DIRECT

Do not use EXT3 or even EXT4. One day BTRFS will get there.

EXT3, and perhaps EXT4, locks at the inode level, not smart!

Sources: - www.mysqlperformanceblog.com - http://dev.mysql.com/doc/internals/en/index.html - Understanding MySQL Internals by Sasha Pachev - https://www.facebook.com/note.php?note_id=10150210901610933 - http://oss.sgi.com/projects/xfs/training/ - Some swing kit, trial and error.

EDIT: An update. EXT4 seems to be doing pretty well as of Mid 2013! BTRFS still isn't a good option. And RHEL may well make XFS the new default file system. Again, do NOT use EXT3.

share|improve this answer
    
According to Vadim Tkachenko's test, EXT4 provides 20% throughput over XFS if MySQL 5.5 with InnoDB are used. Vadim suggests to use 'dioread_nolock' EXT4 option where available (although he didn't use it with the test). –  caligari Jul 3 '13 at 10:53

It may also be worth noting that you can run InnoDB without a filesystem and improve performance without filesystem overhead. I'm not sure I'd recommend it, but I've used it before without issues.

InnoDB Raw Devices

In addition, if you're running at 90% reads and 10% writes, unless you need the transactional ability of InnoDB you might look into porting to MyISAM for better read performance.

share|improve this answer
3  
-1 for suggesting to move to MyISAM for better read performance. Has so much other flaws and downsides. InnoDB should be configured properly instead. +1 for InnoDB-on-raw-device suggestion. –  gertvdijk Dec 12 '12 at 10:14
2  
I stand by my statement, MyISAM has drawbacks but there's plenty of good to be had. MyISAM is still boss for read workloads. –  Xorlev Dec 13 '12 at 6:42

IMHO the worth noting FSs available to linux are:

XFS (poor read speed) known to be light on the system resources and fast with large files but poor to handle lots of small files .

ReiserFS (poor write speed) not very kind on system resources but performs very well with lots of small files.

EXT3 falls in between, performing acceptably on all fields (the reason why its considered the default linux FS).

I have not yet used EXT4 not ReiserFS4 myself but i have looked around some benchmarks and ReiserFS appears to have the best performance when it comes to reading speed, which you said was the most important to you.

Take a look at this : ReserFS4 X Ext4 X Ext3

I would recommend Ext3 for its stability, security and maturity, but if read speed is what is most important to you, you should consider ReiserFS.

Remember that you should also consider CPU usage, stability, security on so on before choosing a FS.

And of course making a pilot, testing and benchmarking on your particular environment is always the best way to tell what will work best for you.

PS: I would have posted more benchmarks but i can't post more than one link.

share|improve this answer

It's not likely to make much difference. Go with whatever your distribution uses as its default, provided it's sufficient.

Spend your effort tuning other things - get enough ram - get a raid controller which doesn't suck - and fix the application's lame (ab)use of the database (NB: this is the main culprit in most cases where it hasn't already been done).

Consider however, carefully, the filesystem you put your mysql tmpdir on; this will affect performance, particularly queries which do disc-based filesort()s (see EXPLAIN for more details).

I think a filesystem which support delayed allocation is really handy here, as you can avoid IO completely for short-lived files when there is enough ram to keep them in the cache. XFS, for instance, doesn't bother writing files at all which get deleted and closed before they've been allocated.

Of course putting a tmpdir on a tmpfs is attractive from a performance perspective, but leads to a risk of exhausting the space and having queries which would otherwise succeed (albeit with disc temporary files used) fail.

share|improve this answer

The short version is that the closest to a recommendation I've seen MySQL make on filesystems is XFS, however ext3 should be ok as well, ext4 promises to be a nice improvement, but it's still not quite stable, although it should be before the end of the year.

If you're running cluster filesystems CXFS, OCFS2 and GFS should all be ok.

I'd strongly warn against any Reiser derivatives, and JFS although once nice has been mostly beaten by XFS and ext4 which are both more widely deployed.

share|improve this answer

I'm not finding any recent articles with benchmark "roundups" on MySQL running on various filesystems. Given the workload you describe, I doubt that file-level fragmentation is going to be much of an issue. Without a formal benchmark, I can't say anything that you should take as authoritative, but my gut says that every filesystem you mentioned above is going to perform roughly in the same ballpark (i.e. all in the same order of magnitude for performance numbers).

The database is really running the show, since the filesystem is just managing large extents that the storage engine is accessing.

Still, it would be interesting to do a performance roundup with all those filesystems. (I have less than no enthusiasm for MySQL, though, so I'm not going to undertake it. Benchmarking Postgres, OTOH, might be interesting...)

share|improve this answer
1  
Thee is also a stackoverflow.com/questions/1021854/… duplicate with some references that might interest you –  nik Jun 20 '09 at 19:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.