What do you think about ext4 filesystem in the production enviroment ? We are very close to launching our project that will use tens of millions quite often updated not very big files and we need to decide which FS to use.

For a while our considerations about other linux FS are:

  • Ext3 is rock stable, but not very well suited for handling millions small files
  • XFS looks very nice, probably we'll use it
  • ReiserFS ... well...vague future, who will end up fixing bugs ?
  • At a previous job, we had huge SGI systems with XFS file systems. At the time, our 96GB array was bigger than the ones SGI had to test, and so when we had problems SGI engineers came out see for themselves. As you can imagine, XFS has had a lot of real world use since then and it seems pretty stable and reliable. – Paul Tomblin Jun 15 '09 at 16:52

If you're at all unsure (and it sounds like you are), stick with the older stuff you know.

That doesn't just apply to filesystems, either. Production equals solid. If you have to ask if something is ready for production, you're not ready to use it for production, and that's what matters.

Make a lab and test it while you deploy ext3 in your production environment.

  • 1
    Agree, stick with ext3 while you test the others. There is no substitute for testing. – pgs Jun 15 '09 at 16:42

It kind of depends on your definition of 'production. Ext4 is just now beginning to make its way into the community distros. For openSUSE, upon which Novell SuSE Linux Enterprise Server is based, ext4 missed SLES11 and will have to wait for SLES12. I don't know the RedHat process well enough to predict. But if you need enterprise linux with support from a company, I expect it'll be a few years before it shows up. If support-contract is your definition of 'ready for production', then that's your answer.

If you're willing to use a Linux without an enterprise support contract, then you're in the land of opinions. Ext4 hasn't been in the kernel all that long, so they're still finding major bugs. In my opinion I'd give it a few more kernel-revs before deploying ext4 in something production. On my desktop? Sure! Servers? I'll wait.


I've been having this very discussion on a LUG mailing list...Since ext4 isn't in a version of Linux that has "enterprise support" I won't use it on a mission critical server...That being said, I have been running it on both my laptop, desktop and server at home (all run F11) and I haven't seen a single issue..I've yanked the plug on my laptop a couple of times to see how well it recovers and everything came back perfectly.

On my workstations I don't mind the risk of running ext4...The only way that it will become stable is if people run it and abuse it so possible bugs can be found and fixed.


Correct me if I'm wrong, but isn't XFS better with large files than small? The MythTV community use it in preference to ext3 for the speed in which it deletes multi-gigabyte files. Or is handling large numbers of files what interests you?

  • ReiserFS ... well...vague future, who will end up fixing bugs ?

Try this in your kernel source tree:

$ ./scripts/get_maintainer.pl -f fs/reiserfs/Makefile  
Jeff Mahoney 

ReiserFS is not the product of one man. ReiserFS v3 is stable and in maintenance mode; it still has a maintainence team, and the only upcoming changes I know of are the removal of the "Big Kernel Lock", a kernel cleanup which should also result in a speed increase (per-superblock locks vs a single shared lock).

The ReiserFS v4 team may have lost their leader and figurehead, but volunteer work still continues, though it has not been merged into the mainline kernel.


FWIW, to this day there's at least one ext4 performance problem with Red Hat Enterprise Linux 5.4 (and 5.5 beta) x86-64 which is easy to trigger on large-memory systems:

time bash -c "dd if=/dev/zero of=10G bs=1M count=10000 && sync"

The sync will run very slow on ext4 compared to ext3 or xfs (~7min vs ~1m on my test system). See my bug report for details.

However, please notice that a) ext4 is only a technology preview in 5.4 and b) vanilla kernels 2.6.32 and 2.6.33 are not affected.

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