On Thu, 2003-02-20 at 23:57, Karl Fogel wrote:
> We do change the file in safe steps behind a static reference point --
> as long as we use some sort of locking mechanism (such as BDB
> transactions) to ensure that the old reference point still has
> something to refer to for as long as it's being used. That's
> inevitable; regular filesystems are doing their own transactioning
> behind the scenes, too.
The difference is that regular filesystems have an atomic update
operation (rename). There may be some kernel locking under the covers,
but if so, it's a very small locking window using very efficient locks.
Berkeley DB also has an atomic update operation (put), but it's not
compatible with using duplicate keys (or DB_APPEND) to create a value in
multiple steps. So we have to use a more heavyweight mechanism
(transactions) to protect readers from writers. I'm not sure if that's
responsible for the scaling problems Brandon is seeing, but it probably
limits our throughput. (Possibly in some nasty ways, since every
transaction touches the root directory.)
> I don't think it has anything to do with separate tables or not. We
> need the lock (or transaction) around read operations because we
> change the way the data is represented.
But you can read without locking if you have atomic updates.
> We could do that just as easily if it were all in one table; and we
> could avoid doing it, while still using separate tables.
You're right; given that we use transactions, I'm not sure why we have
separate representations and strings tables.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 21 07:31:01 2003