[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: FSFS propaganda

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2004-04-30 19:02:38 CEST

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?


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.