====== Issue 1 of 2: ======
I've been looking at FSFS, to confirm that FSFS really doesn't rely on any
of the designed-for-BDB locking support in libsvn_repos.
In most cases, I think everything is safe, because any normal write
operation ought to be taking the fsfs write-lock.
However, hotcopy is a corner case. Current FSFS hotcopy neither takes the
write-lock, nor does it refrain from creating the format file until the FS
is complete in every other way.
If I fix this, is it safe to assume that libsvn_fs_fs is then entirely
self-contained as far as locking is concerned?
====== Issue 2 of 2: ======
On a related note, I think I may have discovered a hotcopy race condition
related to locking:
1. Begin fsfs hotcopy
2. 'current' is copied
3. Whilst copying the (potentially very large) 'revs/' directory, some
activity occurs in the source repo:
A. Commit the addition of a file
B. Lock the added file
4. The hotcopy finishes with 'revs/' and 'revprops/', and now copies
'locks/*'.
OOPS! Now there is a lock in the hotcopied repository, for a path which does
NOT exist in the hotcopied repository.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 24 23:34:29 2005