On Mon, Aug 29, 2011 at 09:38:23PM -0400, C. Michael Pilato wrote:
> You're using the term "cache" alot, which is definitely not the approach I
> took with BDB. In the BDB code, a missing successor map entry would signify
> a corruption of the filesystem.
> Also, the BDB code does all this stuff at the transaction level, not the
> revision level. So, the node revision IDs of uncommitted nodes that live
> under txn roots can be the "value" of a successor-ID mapping. You don't
> have to wait until the transaction is committed before that mapping is
> present or valid. I'm not sure if that's useful or desireable, nor can I
> really tell if it differs from what you are proposing, but as neither the
> word "transaction" nor "txn" show up in your mail, it seemed I should call
> that out.
That's a very good point, thanks Mike!
The semantics of a cache make more sense at the repos-layer,
as described in the log cache design by Stefan^2.
If successor IDs are managed in the FS layer, successors should be
added in a transactional fashion, just like all other changes made
to the FS. The design I proposed doesn't take advantage of this at all.
It is therefore somewhat pointless. A cache might as well be layered
above the FS.
I'll try to tweak my proposal such that successor ID updates become
transactional and happen as part of every commit.
Note that a cache layered above the FS might still be a better idea
because it wouldn't require changes to existing backends and, in
general, solves the problems we're trying to address just as well.
But there is still enough time to explore all our options.
Received on 2011-08-30 12:44:20 CEST