Added-checksum filesystem

[Kip Macy]

Netapp filers already do this. On ZCS disks every 64th file system block
consists of checksums for the other 63. On BCS, sectors are 520 bytes,
so every 4k block has an additional 64 bytes in which the checksum is
stored. This is really only meaningful if you have a parity block (if
it is the parity block that fails the check, than you just re-generate
it) for the stripe to recover the data from, otherwise you are really
only notifying yourself that you've lost data and it is time to restore
from backup.

Few people realize just how crappy today's disks are, the most recent
generation of disks of all classes (ATA, SCSI, FC) have substantially
higher media error rates than the previous generation. For people who
have large disk systems and genuinely depend on the integrity of their
data, what you are suggesting is not idle banter.



			-Kip

On Tue, 18 Nov 2003, Sander Vesik wrote:

> from more or less the department of semi-idle thoughts:
>
> 	lets assume that there is a disk / filesystem where
> 	its important to know that the data coming back from
> 	the disk - via disk, interconnect & pci is the same as
> 	was originaly sent with common errors outruled, and that
> 	the result would not overly suck performance-wise. so
> 	the checksum should be fast tocompute, relatively short
> 	(4-8 bytes per fragment?), and be placed close to data
> 	- probably in the same cylinder group and distributed to
> 	be next to the data it covers.
>
>
>
> --
> 	Sander
>
> +++ Out of cheese error +++
>