> > well, there's your problem. you corrupted > > the cache, not the venti store. (you have no > > venti store in this example.) > > I was specifically referring to a "normal operations" > to conjure an image of a typical setup of fossil+venti. > > In such a setup a corrupted block from a fossil > partition will go undetected and could end up > being stored in venti. At that point it will become > venti "problem".
it's important to keep in mind that fossil is just a write buffer. it is not intended for the perminant storage of data. while corrupt data could end up in venti, the exposure lies only between snapshots. you can rollback to the previous good score and continue. ken's fs has a proper cache. a corrupt cache can be recovered from by dumping the cache and restarting from the last good superblock. in the days when the fs was really a worm stored on mo disks, the worm was said to be very reliable storage. with raid+scrubbing we try to overcome the limitations of magnetic media. while there isn't any block checksum, there is a block tag. tag checking has spotted a few instances of corruption on my fs. fs-level checksumming and encryption is definately something i've considered. actually, with tags and encryption, checksumming is not necessary for error detection. - erik
