| |||||||||||||
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:05 UTC (Tue) by Cato (subscriber, #7643)In reply to: Ext3 and write caching by drives are the data killers... by dlang Parent article: Ext3 and RAID: silent data killers?
Possibly data=journal is overkill, I was going by the Wikipedia page on ext3, link above. However a conservative setup is attractive at present as performance is far less important than reliability, for this PC anyway.
Do you know roughly when ext3 checksums were added, or by whom, as this contradicts the Wikipedia page? Must be since 2007, based on http://archives.free.net.ph/message/20070519.014256.ac3a2.... I thought journal checksumming was only added to ext4 (see first para of http://lwn.net/Articles/284037/) not ext3.
This sort of corruption issue is one reason to have multiple partitions; parallel fscks are another. In fact, it would be good if Linux distros automatically scheduled a monthly fsck for every filesystem, even if journal-based.
(Log in to post comments)
Ext3 and write caching by drives are the data killers... Posted Sep 1, 2009 18:15 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
Ted Tso detailed the protection of the journal in this thread (I've deleted the particular message or I'd quote it for you)
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.
Ext3 and write caching by drives are the data killers... Posted Sep 1, 2009 18:44 UTC (Tue) by Cato (subscriber, #7643) [Link]
I still can't find that email, but this outlines that journal checksumming was added to JBD2 to support ext4: http://ext4.wiki.kernel.org/index.php/Frequently_Asked_Qu...
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.
Ext3 and write caching by drives are the data killers... Posted Sep 2, 2009 6:36 UTC (Wed) by Cato (subscriber, #7643) [Link]
I grepped the 2.6.24 sources, fs/ext3/*.c and fs/jbd/*.c, for any mention of checksum, and couldn't find it. However the email lists do have some reference to a journal checksum patch for ext3 that didn't make it into 2.6.25.
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...
|
|||||||||||||