On Monday 31 May 2010 19:59:46 Paul Millar wrote: > Hi Hubert, > > On Thursday 27 May 2010 16:56:00 Hubert Kario wrote: > > > Would [obtaining file checksum] be possible (without an awful lot > > > of work)? > > > > [Calculating checksum in-memory] won't detect in-memory corruption > > though, but if you want to be resilant to this, you should be looking at > > > > ECC RAM as subsequent checks can be affected by it to. > > Certainly ECC RAM will help, but unfortunately it doesn't remove the > possibility of corruption; for example, CERN found [1] that double-bit > memory corruptions (which ECC cannot recover from) can still happen. > > [1] > http://indico.cern.ch/getFile.py/access?contribId=3&sessionId=0&resId=1&mat > erialId=paper&confId=13797 > > Also, IIRC there was a case where Fermilab tracked down a data corruption > to a faulty PCI bus in the server. So who knows where are all the places > corruption could occur? > > I guess the real problem is that, when processing large amounts of data, > these rare occurrences start to stack up. >
Yes, but AFAIK btrfs checksums don't have internal checksum (e.g. you can't check if the read checksum is a valid one or not, it does not have control bits), as such, if you consider PCI bus corruption as likely, you still don't get 100% certanity that the data reached the HDD unharmed. If you need such level of certanity when recording data, I'd consider mainframe hardware and/or duplicating whole storage stack. Cheers, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl System Zarządzania Jakością zgodny z normą ISO 9001:2000 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
