[9fans] venti

[ggm@apnic.net (George Michaelson)]

Say you co-elesce the same blockset down to one common instance for
a large number of files, and then lose that block because a fly shits
on the write-once media.

Didn't you just lose that bitpattern in time, across your entire archival
filestore?  Oooh. me no like.  I suppose that is exactly what happens to
99% of dataloss anyway, if you believe its mostly unique data.

This is precicely why holotype fossils are not on display: they are too
valuable to expose to risk of catastrophic loss.

Protection of an entire venti filestore would thus mean either 2x the data
size to replicate, or some sub-fraction to ECC check it, for some chosen
level of protection. I suppose thats still better than having 300 repeat
instances of the BSD copyright on every manpage. I notice in the paper
the authors say "doable, but we didn't bother" which means until somebody
in the operations space does budget-up for the offsite archive, and some
checks to make sure the copy is 1:1 acceptable, the venti filestore is
a bit more risky than you might want. Even backed on RAID5, it can lose
bigtime from some failures. Might be nice for @home fs, on IDE raid mind you!

This also looks to have resonances with rsync, in a data persistant state
instead of for update of two copies of the same resource. The rsync papers
discuss finding good hash algs and good blocksizes to make this work. No
citation, perhaps if you followed the rsync citation index back they'd wind
up in the same prime sources. I guess the venti authors knew about rsync but
don't see it as having relevance.

Do you get nice COW form savings in memory/load time because every pointer
can walk through the same memory reference to find the string? That could
be really nice!

And, it would make smaller footprints on tiny devices as well.

cheers
	-George