All of my production systems use XFS for the last 5-10 years. I never liked the idea that we have 5 filesystems on Linux an you have to know which is better for your use case, while other Unix like systems offer you maybe 2 options but there is one that is supported and recommended (like ZFS on Solaris). I think ext4 does not offer too much for the most of the users over ext3 but given its history (lots of data loss scenarios) I would not want to risk it to start to use it in production. On the top of that, the recent moves from CentOS to use XFS as the default FS just makes me think I made the right decision 10 years ago to use XFS for almost everything I do.
Ted Tso about ext4:
> P.S. It's bugs like these which is why I'm always amused by people
> who think that just because a file system is safely being used by
> their developers, that it's safe to throw production workloads on
XFS doesn't have an impressive track record when it comes to data loss, either. Come on people, every filesystem with large number of users has had their screw-ups.
True. I am not, however, aware of the XFS developers ever deliberately changing the behaviour of an older version of XFS to make it less safe to match the data corruption problems in a newer version.
Well I am not sure about that, as anecdotal evidence, most systems engineers I know use XFS as default on their systems. This might be coincidence, but I think it is just a sign that XFS has less "screw-ups" than ext3/4. A representative survey would help to prove it.
Well, if we're going by anecdotal evidence, I've had a big loss when an XFS-on-RAID system had a power failure about 4 years ago, and recently I know someone who's lost hundreds of gigs to XFS as well, with no power loss that he's aware of.
/dev/md127 on /home/data type ext4 (rw,relatime,stripe=1792,data=ordered)
Ext3 was 32k, but ext4 is 65k subfolder limit. I have run into this one before. The real solution is to do directory hashing when you get this crazy with tons of subfolders.
Oh, I see. You were remarking on edgan's use of the phrase "Ext4 does support".
So, firstly, both Red Hat and ext4 support FSs larger than 16TB. So, yeah.
Secondly, I mean, Ted Ts'o works for Google, rather than Red Hat, so it's not like Red Hat has any special insight into the inner workings of ext4. RHEL's lack of "support" for ext4 FSs large than a certain size wouldn't make me wary of using FSs larger than that size.
Ts'o & co. seem to be pretty careful, so I would expect that the worst that would happen would be performance issues.
Regarding Tso & co, I am not so optimistic. How they communicate on the mailing list is more like: "Look we wrote this, it runs on my laptop fine it might work for other workloads too".
There is no extensive test coverage run by against ext4 (at least I am not aware of it). This is not the first data loss bug in the ext4 codebase. Few years from now when enough users start to use it an get rid off these serious bugs from the code, I might even consider POCing it again.
I'm somewhat certain that -despite the name- xfstests [0] is the canonical filesystem test suite these days. (At least, I've heard the btrfs devs concerned about passing its tests and adding new tests in it to check corner cases in btrfs. I also remember hearing the ext4 devs mention xfstest.)
I read that mailing list tone as something more like "This software is offered without warranty and might shave your dog and weld your toilet seat down.". I mean, folks on the LKML talk in that manner about their patches, too.
Also, even XFS has had severe data loss bugs in the distant past [1] and much more recently. [2]
Thank you, #1 might be the biggest reason that XFS is used over ext4 I guess, 16TB is not as unusual size for a decent raid array nowadays. I would like to understand why CentOS (and I guess RedHat went for XFS) though.
Ted Tso about ext4:
> P.S. It's bugs like these which is why I'm always amused by people
> who think that just because a file system is safely being used by
> their developers, that it's safe to throw production workloads on
> them.