> As for me, here's my wish list so far. It is all about fossil, since > it looks like venti is quite fine (at least for my purposes) the > way it is: > 1. Block consistency. Yes I know the argument here is that you > can always roll-back to the last known archival snapshot on venti. > But the point is to kown *when* to roll back. And unless fossil > warns you that a block has been corrupted you wouldn't know.
I don't understand what you mean. Do you want fossil to tell you when your disk is silently corrupting data, or something else? > 2. live "mounting" of arbitrary scores corresponding to vac > VtRoot's to arbitrary sub-directories in my fossil tree. After > all, if I can do "create" of regular files and sub-directories > via fossil's console why can't I create pointers to the existing > venti file-hierarchies? The only reason this is hard is the choice of qids. You need to decide whether to reuse the qids in the archive or renumber them to avoid conflicts with existing qids. The vac format already has a way to offset the qids of whole subtrees, but then if you make the tree editable and new files are created, it gets complicated. > 3. Not sure whether this is a fossil requirement or not, but I > feel uneasy that a root score is sort of unrecoverable from the > pure venti archive. Its either that I know it or I don't. I don't understand what you mean here either. >From a venti archive, you do cat file.vac to find the actual score. For what it's worth, I'll be the first to admit that fossil has a ton of rough edges and things that could be done better. There were early design decisions that we didn't know the implications of until relatively late in the implementation, and I would revisit many of those if I had the luxury of doing it over. It is very much version 0. The amazing thing to me about fossil is how indestructable it is when used with venti. While I was finishing fossil, I ran it on my laptop as my day-to-day file system, and I never lost a byte of data despite numerous bugs, because venti itself was solid, and I always did an archive to venti before trying out new code. Once you see the data in the archive tree, you can be very sure it's not going away. > It is actually quite remarkable how similar the models of > fossil/venti and Git seem to be: both build on the notion > of the immutable history. Both address the history by the > hash index. Both have a mutable area whose only purpose > is to stage data for the subsequent commit to the permanent > history. Etc. I don't think it's too remarkable. Content hash addressing was in the air for the last decade or so and there were a lot of systems built using it. The one thing it does really well is eliminate any worry about cache coherency and versioning. That makes it very attractive for any system with large amounts of data or multiple machines. Once you've gone down that route, you have to come to grips with how to implement mutability in a fundamentally immutable system, and the obvious way is with a mutable write buffer staging writes out to the immutable storage. > Hm. There doesn't seem to be much of shutdown code for fossil/venti > in there. Does it mean that sync'ing venti and then just slay(1)'ing > it is ok? Yes, it is. Venti is designed to be crash-proof, as is fossil. They get the write ordering right and pick up where they left off. They are not, however, disk corruption-proof. Russ
