Ext3 and write caching by drives are the data killers...
Ext3 and write caching by drives are the data killers...
Posted Sep 1, 2009 18:15 UTC (Tue) by dlang (guest, #313)In reply to: Ext3 and write caching by drives are the data killers... by Cato
Parent article: Ext3 and RAID: silent data killers?
I'm not sure I believe that parallel fscks on partitions on the same drive do you much good. the limiting factor for speed is the throughput of the drive. do you really gain much from having it bounce around interleaving the different fsck processes?
as for protecting against this sort of corruption, I don't think it really matters.
for flash, the device doesn't know about your partitions, so it will happily map blocks from different partitions to the same eraseblock, which will then get trashed on a power failure, so partitions don't do you any good.
for a raid array it may limit corruption, but that depends on how your partition boundaries end up matching the stripe boundaries.
Posted Sep 1, 2009 18:44 UTC (Tue)
by Cato (guest, #7643)
[Link]
This Usenix paper mentions that JBD2 will ultimately be usable by other filesystems, so perhaps that's how ext3 does (or will) support this: http://www.usenix.org/publications/login/2007-06/openpdfs... - however, I don't think ext3 has journal checksums in (say) 2.6.24 kernels.
Posted Sep 2, 2009 6:36 UTC (Wed)
by Cato (guest, #7643)
[Link]
One other thought: perhaps LVM is bad for data integrity with ext3 because, as well as stopping barriers from working, LVM generates more fragmentation in the ext3 journal - that's one of the conditions mentioned by Ted Tso as potentially causing write reordering and hence FS corruption here: http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-05/m...
Ext3 and write caching by drives are the data killers...
Ext3 and write caching by drives are the data killers...