> > it's important to keep in mind that fossil is just a write buffer. > > it is not intended for the perminant storage of data. > > Sure. But it must store the data *intact* long enough > for me to be able to do a snap. It has to be able to > at least warn me about data corruption.
do you have any references to spontaenous data corruption happening so soon on media that can be written elsewhere without corruption? ian ibm paper argus for raid[56] + chksum that claimed that the p(lifetime) = 10^-13. http://domino.watson.ibm.com/library/cyberdig.nsf/80741a79b3d5f4d085256b3600733b05/ca7b221ad09be77885257149004f7c53?OpenDocument&Highlight=0,RZ3652 but i didn't see any reason that this would apply to short-term storage. > That is my *entire* point. If fossil doesn't tell you that > the data in its buffer was/is corrupted -- you have no > reason to rollback. if you're that worried, you do not need to modify fossil. why don't you write a sdecc driver that as configuration another sd device and a blocksize. then you can just add ecc on the way in and check it on the way out. - erik
