On 08/26/2011 07:14 AM, Stefan Sperling wrote:
> cmpilato, does this significantly differ from what you've done for BDB?
> Will both backends have the same (or similar) behaviour if we use
> this design for FSFS?
Most of what you discuss in this proposal is related to the detailed
properties of the storage layer for successor-id mapping, all of which is
completely irrelevant to the BDB scenario where a real database engine with
well-defined semantics for this sort of thing already exist.
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. I can't recall for sure, but I don't
believe I allowed for a way to distinguish between "This node has no
successors" and "This node's successors haven't been calculated yet". (And
that was likely because I didn't want to also have to deal with "This node's
successors have been only partially calculated.") Of course, it's not that
the data isn't calculable from the predecessor links we already store, but
simply that the code assume that the table has been properly maintained
since the origin of the repository, or at least backfilled in its entirety
while the repository was offline. Not "cache"-like at all.
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.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-08-30 03:38:58 CEST