Hacker News Reader

Comment by rbanffy | Hacker News Reader

"This recent mess with filesystem write semantics (http://lwn.net/Articles/322823/ ) has proven you can't even rely on POSIX."

I have to disagree.

The "problem" resides in the way ext4 writes data to the disk. If you need crash-resistance (the data-loss occurs on computer crashes) ext4 is not for you. And keep in mind if you really need it, ext3 isn't for you either. JFS or XFS, perhaps, and ZFS, but I never intentionally crashed a machine with unwritten data since, perhaps, my Apple II days.

This has nothing to do with POSIX.

View on HN

I have several hundred million files stored on XFS, not sure if that's a lot or a little by HN standards, but maybe it counts for something.

We will never ever have another XFS setup with a filesystem where deletions are to be expected. XFS works fine as long as you are just adding files to the filesystem, deletions are pathologically slow.

We've tried just about every trick in the book and have finally made the decision to switch back to ext3, which given the number of files will take a while.

So, that's nothing against XFS from a reliability point of view, but definitely from a performance point of view.

Interesting. I had a meeting where XFS got high praises from a very knowledgeable person. The catch is that in this solution, files are added and appended and very seldom deleted.

Our usage is pretty specific, it took us a while to narrow this down to XFS mainly because it was hard to believe how slow it was.

Deletion can be much slower than file creation if the files are small.

If you google for 'xfs delete speed' you'll get plenty of bits of information, the best fix was the 'nobarrier' option.

Deleting files at random is especially bad.

Deletion can be much slower than file creation when the files are hundreds of mb too!

Worst of all, "rm -R" runs right into XFS's most pathological case -- it's doing tons of metadata reads while it unlinks files, and XFS shoves a lock in every orifice.

Ext4 - is badly configured Ext3 (data=writeback mode) with extents support. By default, in recent kernels, Ext3 is configured in same way as Ext4 (data=writeback). In RedHat/Fedora/CentOS/etc., Ext4 is configured properly (data=ordered): "Don't worry about the new default journaling mode for ext3 planned for 2.6.30 (data=writeback, which is much faster than the old default, data=ordered, but has enormous security and data integrity problems). No distro would ship this as the default. The only way it could happen at Red Hat is over the dead bodies of the security team, who, let me tell you, keep an eagle eye on file system data leaks like this."

Ext4 is not alone - other file systems (Ext3, XFS, maybe others) are patched to support new file rewrite semantic too.

PS. I saw lot of zero-padded files on XFS until switched to Ext3 with data=ordered.

Can this be selected by mountpoint at /etc/fstab ?

Yes, in the options field.

Reply on news.ycombinator.com