On Sat, Oct 27, 2012 at 09:56:45PM +0000, Michael Kjörling wrote: > I came across the tidbit that ZFS has a contract guarantee that the > data read back will either be correct (the checksum computed over the > data read from the disk matches the checksum stored on disk), or you > get an I/O error. Obviously, this greatly reduces the probability that > the data is invalid. (Particularly when taken in combination with the > disk firmware's own ECC and checksumming.) > > With the default options, does btrfs make any similar guarantees? If > not, then are there any options to force it to make such guarantees?
It does indeed do the same thing: if the checksum doesn't match the block, then the alternative block is read (if one exists, e.g. RAID-1, RAID-10). If that does not exist, or also has a checksum failure, then EIO is returned. Hugo. > I'm interested in this both from a specification and an implementation > point of view. > > The last thing anyone wants is probably undetected bit rot, and with > today's large drives, even with the quite low bit rot numbers it can > be a real concern. If even the act of simply successfully reading a > file guarantees, to the extent of the checksumming algorithm's ability > to detect changes, that the data read is the same as was once written, > that would be a major selling point for btrfs for me personally. > > The closest I was able to find was that btrfs uses crc32c currently > for data and metadata checksumming and that this can be turned off if > so desired (using the "nodatasum" mount option), but nothing about > what the file system code does or is supposed to do in the face of a > checksum mismatch. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- It used to take a lot of talent and a certain type of --- upbringing to be perfectly polite and have filthy manners at the same time. Now all it needs is a computer.
signature.asc
Description: Digital signature
