Re: [9fans] Ideas for gc on venti

[a@9srv.net]

// 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.