Hacker News new | ask | show | jobs
by sespindola 5251 days ago
As mentioned on the article's comments, when I used XFS about 8 years ago, I found exceptionally prone to data corruption.

It remains the only filesystem that I couldn't at least partially recover.

For a good mix of speed, reliability and huge data capacity on Linux, I stick to ReiserFS, at least until btrfs becomes more stable.

7 comments

8 years ago would make you an extremely early adopter of the Linux port. XFS has seen significant development since then. I don't think experiences based on eight year old software hold much water.

XFS has adopted some nasty stigma of being a filesystem that eats your data. But it seems that for every user that complains about data loss, another does not.

> But it seems that for every user that complains about data loss, another does not.

So, a coin toss then? You're not helping!

No, we need a careful investigation of the filesystem.

Listening to my "works fine" comment is as useless as any other "didn't work for me" comment.

What might be helpful is a comment saying "I encountered the following issues with the following configuration, reported the bug, and the maintainers said ..." What would be even better would be for actual experts to audit the code, look through the bug reports, and give their opinions.

But "works for me"/"broke for me" comments are, unfortunately, as useless as most filesystem benchmarks. Indeed, any time filesystem discussions come up, a stunning majority of the opinions are unhelpful. Unfortunately, I jumped right in with one as well :(

Agreed, I was using XFS aggressively on ~20 servers with wildly varying IO loads 4-5 years ago and it was rock solid.
My experience with XFS and Arch Linux is that it is rock solid.
That sad part is that a lot of what was perceived as data loss from XFS was actually due to bugs in apps & the kernel that XFS exposed. These same issues would show up with ext4 & btrfs, but XFS has already flushed them out so they've been fixed.
I was using XFS on a production web/ftp server (RedHat 7.x with XFS patches) in or around 2001. The port was done in 2000. I don't think a 4 year old port of a 10 year old file system is that extreme. That said, I've been using ZFS in FreeBSD since FreeBSD 7.
It's a FAQ:

http://xfs.org/index.php/XFS_FAQ#Q:_What_is_the_problem_with...

In summary: XFS used to default to having write-barriers disabled (for performance), which makes it prone to data-loss during power outages. This default has changed nowadays, but you must still review your controller-/disk-cache settings to ensure stuff is really flushed to disk when XFS thinks it is.

I've actually been moving off of ReiserFS myself. Mostly for some of the known bugs and unfixable problems with it relating to storing another ReiserFS image on it and then trying to recover data from a crash. I've run into that more than once and that made me move to something that was a little more sane during recovery (ext3 at the time, now ext4).
I've never had a problem with XFS, but I had several silent data corruption issues with ReiserFS after power losses, where I would find the contents of one open file intermixed in another open file. I think such problems have been fixed now, but I ended up losing trust in ReiserFS at that point.
5 or 6 years ago, it took a single power failure to basically screw up my filesystem. From the comments on the article, it seems it's not really a solved issue (or rather, people don't consider that an issue).

I'd think again before using XFS on my desktop.

(I've had power failures on quite a few other occasions, with all sorts of other filesystems. I did lost the occasional file, but at least I could still boot those systems..)

Same experience here. And after xfs_repair, still remaining files and directories which couldn't be deleted or moved. The only solution to move the parent folder or reformat. Though performance wise, it was really fast.
I had the same experience concerning XFS, I experienced repeated data loss on power failure about 4 years ago. These days I just stick with ext4