Re: Checksumming blocks? [was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

Russell Leighton
2006-08-03T23:57:57Z

Thx, for a db this seems natural...

I am very curious about ZFS as I think we will seem more protection in
the FS layer as disks get larger...
If I have a very old file I am now half way throught reading and ZFS
finds a bad block, I assume I would
get some kind of read() error...but then what? Does anyone know if there
are tools with ZFS to inspect the file?

Matthias Andree wrote:

>(I've stripped the Cc: list down to the bones.
>No need to shout side topics from the rooftops.)
>
>On Thu, 03 Aug 2006, Russell Leighton wrote:
>
>
>
>>If the software (filesystem like ZFS or database like Berkeley DB)
>>finds a mismatch for a checksum on a block read, then what?
>>
>>
>
>(Note that this assumes a Berkeley DB in transactional mode.) Complain,
>demand recovery, set the panic flag (refusing further transactions
>except close and open for recovery).
>
>
>
>>Is there a recovery mechanism, or do you just be happy you know there is
>>a problem (and go to backup)?
>>
>>
>
>Recoverability depends on log retention policy (set by the user or
>administrator) and how recently the block was written. There is a
>recovery mechanism.
>
>For applications that don't need their own recovery methods (few do),
>db_recover can do the job.
>
>In typical cases of power loss or kernel panic during write, the broken
>page will probably either be in the log so it can be restored (recover
>towards commit), or, if the commit hadn't completed but pages had been
>written due to cache conflicts, the database will be rolled back to the
>state before the interrupted transaction, effectively aborting the
>transaction.
>
>The details are in the Berkeley DB documentation, which please see.
>
>
>