Improving ext4: bigalloc, inline data, and metadata checksums
Improving ext4: bigalloc, inline data, and metadata checksums
Posted Dec 5, 2011 16:29 UTC (Mon) by wookey (guest, #5501)In reply to: Improving ext4: bigalloc, inline data, and metadata checksums by tytso
Parent article: Improving ext4: bigalloc, inline data, and metadata checksums
When I managed to repair them I found that many files had big blocks of zeros in them - essentially anything that was in the journal and had not been written. Up to that point I had naively thought that the point of the journal was to keep actual data, not just filesystem metadata. Files that have been 'repaired' by being silently filled with big chunks of zeros did not impress me.
So I now believe that XFS is/was good, but only on properly UPSed servers. Am I wrong about that?
Posted Dec 5, 2011 17:03 UTC (Mon)
by dlang (guest, #313)
[Link]
XFS caches more stuff than ext does, so a crash looses more stuff.
so XFS or ext* with barriers disabled is not good to use, For a long time, running these things on top of LVM had the side effect of disabling barriers, it's only recently that LVM gained the ability to support them
JFS is not good to use (as it doesn't have barriers at all)
note that when XFS is designed to be safe, that doesn't mean that it won't loose data, just that the metadata will not be corrupt.
the only way to not loose data in a crash/power failure is to do no buffering at all, and that will absolutely kill your performance (and we are talking hundreds of times slower, not just a few percentage points)
Improving ext4: bigalloc, inline data, and metadata checksums