// combining functionality that is logically distinct is // generally called unmodular, and a layering violation // in this particular senerio.
i agree with the principle, but i'm not sure it applies in this case. what's described (at least the part before any "garbage" collection is done) is really just arena management, not disk management. the arenas are all defined within venti, and nothing underneath really has any understanding of how (or if) they're being used. i don't think there's anything conceptually wrong with asking venti to be able to manage which arenas are "live" or not. of course, i think the specific "deprecated" suggestion is predicated on the idea that you're going to periodically scan the entire data log, which doesn't seem like an assumption that's going to scale all that well (especially in light of the stated goal of eventual distribution). and this is certainly not a defense of the garbage collection idea. i'd be quite averse to any form of automated garbage collection in venti. i've got a few scores written down in a notebook which aren't in any root and don't duplicate blocks in any fs (unless by accident). it would be nice to be able to selectively & manually mark a given score as "deprecated" and have any blocks only associated with that score freed (i've got a few hundred MB already "wasted" on my venti based on having put a space in a vac command line in the wrong place, for example), but i find russ' point about the code to touch written blocks being entirely bug-free based on not existing to be pretty darn compelling. that level of safety is worth a lot. anthony ps: what'd make me give up on the deletion idea entirely is some form of authentication in venti, even if it's just allowing fossil to connect to it via tls using certificates. i can deal with my own mistakes, but it does make me slightly uncomfortable being open to DoS attacks.
