Developer interview: Eric Sandeen on ext4 implementation

Not once did we have an XFS that had it's structure damaged, it was the only filesystem that behaved that way. What you say about blocks being zeroed during writes is true and that was advantageous as we could easily determine when and where in our data streams the power failure happened and didn't have to monkey around guessing if the data was some how missing portions. There aren't good semantics defined as to what should happen to the data in a file during a write and a power failure. It's also worth noting that this was usually a very very small amount of data that was actually actively being written, you could have dozen of files open for write and unless they had unsynced buffers, they were fine. I don't have the exact numbers in front of me at the moment but ext3 rendered itself broken under 1% of the time I want to say like 17 times out of 10000 power-cycle tests, Reiserfs 3 was more prone to breaking, more than 1% and I forget the JFS numbers but I want to say it was between ext3 and Reiserfs.

I guess it depends on how you measure robustness and reliability, having one of the few files being actively written to lose a couple blocks was thought to be better than the whole thing not being mountable and losing all of the other files too.

I wouldn't say it has a mystique around it, it's a very fine piece of software, it's very good at some things and somewhat average at others; unfortunately it's not the best supported piece of code in the Linux kernel and it seems to be prone to kernel panics as some parts of the kernel are updated and that gives me pause. It's unusual how the kernel community at large hasn't really embraced it and that's somewhat fascinating. I'd not exactly encourage folks to run it but that wouldn't be because of reliability, it would be because of support.

Some years back, there was a post to lkml from someone doing filesystem reliability testing.
This was before reiserfs had ordered writes.  And the fellow was asking for help to determine
what was wrong with his methodology.  You see, in his tests, in which power was removed at
random times, over and over, reiserfs, jfs, and xfs all performed about the same.  But ext3
never showed to have dropped anything.  He was quite certain that he must be doing something
wrong.  Turned out it was the ordered writes that made the difference.  I've tried to locate
that thread a few times, over the years, but never been able to find it again.

I've also noted more complaints from desktop users about it eating their data than for other
filesystems. 

I believe that the reason that the kernel guys are not so hot on XFS is that it is:

1. Big and complex

2. Has an ugly glue layer to make it interface to the Linux VFS.

And face it, as well designed ibn the 90s as it might have been... it was still designed in
the 90s.

I'm quite anxious to see how btrfs shapes up!

The XFS page has a FAQ about this.

XFS does not leave garbage in datablocks after an unclean shutdown. Doing so would be a security hole. And, the filesystem is not explicitly zeroing anything - what is going on is that a truncate may happen which removes extents from a file, and then an extending write is done. Because XFS uses delayed allocation, which waits until flush to actualy allocate data blocks, it is possible that, depending on when the crash occurs, you have metadata on-disk with a file size but no extents - i.e., a sparse file. XFS is not explicitly zeroing any blocks; at this point in time the file has no blocks. And so you see nulls when you read, just as you would with a sparse file. Some of this has to do with applications (im)properly looking after their data - see for example Stewart Smith's LCA talk.

Recent changes to XFS have alleviated this problem by forcing a flush on file close when a file has been through these operations.

Also, this business about flux capacitors or whatnot in SGI hardware is total bunk, as far as I know. I know that this is taken as an article of faith on the interwebs, but I do not think it is correct.

One big hardware issue w.r.t. any journaling filesystem is the write cache in disks, because the filesystem must know when writes are truly safe on disk. XFS has write barriers enabled by default whenever the underlying storage allows it which, despite some performance overhead, is critical to ensure filesystem integrity after a crash. Due to implementation details, XFS journaling may be more susceptible to write cache problems, but in general it will affect any journaling filesystem.

"""
Also, this business about flux capacitors or whatnot in SGI hardware is total bunk, as far as
I know. I know that this is taken as an article of faith on the interwebs, but I do not think
it is correct.
"""

Thanks for the info.  But about the capacitors, I was just repeating what Ted Tso has said.
:-)