Ext3 and write caching by drives are the data killers...
Ext3 and write caching by drives are the data killers...
Posted Sep 9, 2009 20:35 UTC (Wed) by BackSeat (guest, #1886)In reply to: Ext3 and write caching by drives are the data killers... by Cato
Parent article: Ext3 and RAID: silent data killers?
It's acknowledged that ext3's lack of journal checksumming can cause corruption
It may only be semantics, but it's unlikely that the lack of journal checksumming causes corruption, although it may make it difficult to detect.
As for LVM, I've never seen the point. Just another layer of ones and zeros between the data and the processor. I never use it, and I'm very surprised some distros seem to use it by default.
Posted Sep 10, 2009 20:50 UTC (Thu)
by Cato (guest, #7643)
[Link] (2 responses)
In the absence of ext3 journal checksumming, and if there is a crash requiring replay of this journal block, horrible things will happen - presumably garbage is written to various places on disk from the 'journal' entry. One symptom may be log entries saying 'write beyond end of partition', which I've seen a few times with ext3 corruption and I think is a clear indicator of corrupt filesystem metadata.
This is one reason why JBD2 added journal checksumming for use with ext4 - I hope this also gets used by ext3. In my view, it would be a lot better to make that change to ext3 than to make data=writeback the default, which will speed up some workloads and most likely corrupt some additional data (though I guess not metadata).
Posted Sep 10, 2009 21:05 UTC (Thu)
by Cato (guest, #7643)
[Link] (1 responses)
Posted Sep 11, 2009 16:33 UTC (Fri)
by nix (subscriber, #2304)
[Link]
(this is all supposition from postmortems of shagged systems. Thankfully
Ext3 and write caching by drives are the data killers...
Ext3 and write caching by drives are the data killers...
Ext3 and write caching by drives are the data killers...
notice that 'hey, this doesn't look like a journal' once the record that
spanned the block boundary is complete. But that's a bit late...
we no longer use hardware prone to this!)