Greg Hudson wrote:
> Note: Recovery
> --------------
>
> If a process terminates abnormally during a read operation, it should
> leave behind no traces in the repository, since read operations do not
> modify the repository in any way.
>
> If a process terminates abnormally during a commit operation, it will
> leave behind a stale transaction, which will not interfere with
> operation and which can be removed with a normal recursive delete
> operation.
>
> If a process terminates abnormally during the final phase of a commit
> operation, it may be holding the write lock. The way locking is
> currently implemented, a dead process should not be able to hold a
> lock, but over a remote filesystem that guarantee may not apply.
> Also, in the future, FSFS may have optional support for
> NFSv2-compatible locking which would allow for the possibility of
> stale locks. In either case, the write-lock file can simply be
> removed to unblock commits, and read operations will remain
> unaffected.
What if a process dies while rewriting the 'current' file? It seems
like we might want to make 'svnadmin recover' able to reconstruct that file.
In a somewhat related issue, the last time I looked, the reading of
various files in the fsfs filesystem (current, revprops, etc) isn't
locked, despite the fact that those files can be changed. Should we be
using apr_file_lock to obtain read locks on them while they're being
read, to avoid the possibility of reading while they're being rewritten?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 30 19:03:21 2004