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.