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

From: Russell Leighton
Date: Thu Aug 03 2006 - 19:55:41 EST

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

The details are in the Berkeley DB documentation, which please see.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at