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

Re: Fixing the FSFS corruption bug

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2006-09-07 14:44:51 CEST

On Tue, Sep 05, 2006 at 09:29:27PM +0100, Malcolm Rowe wrote:
> + err = svn_io_file_open(file, path_txn_proto_rev_lock(fs, txn_id, pool),
> + pool);

So I've just noticed that this method of creating a lockfile (using
O_CREATE|O_EXCL) appears to be broken on NFSv3 mounts on Linux pre-2.6.5
(including all 2.4 kernels), as described in [1], and as far as I can
tell, isn't supported on NFSv2 at all ([2] backs this up, to some extent).

Now, we don't support FSFS-on-NFSv2 as far as I'm aware, but I'd quite
like to support 2.4 kernels for just a while yet :-). Also, I've no idea
whether the same behaviour might not exist in NFS clients for other OSs.

So I guess I either need to duplicate the mutex-and-fcntl dance that
the FSFS code does with the fs-wide write lock, and work out some way of
stashing a per-transaction mutex somewhere, or alternatively look into
playing the NFSv2 link() dance, which I think actually works everywhere.

The former looks like it should work: I can create a hash of 'known'
transactions in fs_serialized_init, located via an APR userdata pointer,
and then stash a per-transaction mutex into that hash, deleted on
transaction commit/purge. The mutex will 'leak' if the caller abandons
the transaction without committing or purging, in just the same way that
the transaction remains on disk; I think that this should be okay,
since I don't expect that many callers abandon transactions without
committing them - though I can envisage convoluted scenarios where it
would be a problem.

I'd appreciate some feedback on the current patch's concept first,
before I go down the route of changing the implementation to work on NFS.


[1] http://nfs.sourceforge.net/#faq_d10
[2] http://web.mit.edu/ghudson/info/fsfs

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 7 14:45:32 2006

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.