Hacker News Reader

Comment by uriel | Hacker News Reader

I used XFS for years, until I got tired of it semi-randomly overriding my files with zeros and then found out that apparently this was 'by design', after that I stick with ext3/4 that might not be as fast in some corner cases, but which are just as fast or more with my usage patterns, and which so far has been good at not corrupting any of my data.

View on HN

semi-randomly overriding my files with zeros and then found out that apparently this was 'by design

Can you elaborate on this?

I'm using XFS in a few fairly large deployments and so far without any problems. Should I worry?

I believe not, unless you are in the habit of losing power without getting a chance to unmount your filesystems cleanly.

Someone please correct me if I'm wrong, but my understanding is that it's something approximately like this:

In the event of an error and journal replay, the filesystem metadata can be recovered, but not necessarily the data itself. ext3 tries to keep your data intact, or at least as much of it as it can piece back together. XFS (and I think JFS), if they don't know for sure that all the data is intact, just zero the file. This is by design, on both sides.

So in normal usage everything is fine; it's just a difference in error handling.

No, because XFS doesn't eat your data if you're using decent hardware with decent applications. See

http://flamingspork.com/talks/2007/06/eat_my_data.odp

It's probably not the best choice for a basic desktop without UPS, though, or a laptop.

XFS Zeroes the block instead of keeping the random/sensitive data that was already on the disk if the metadata necessary for that write was not commited before the failure. Ext leaves the data as is.

If you want full protection against those situations instead of praying that it's still the right data or that it doesn't happen at all, you need a copy-on-write FS, or enable data=journal on ext3, at a massive performance cost.

Reply on news.ycombinator.com