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),
> + APR_WRITE | APR_CREATE | APR_EXCL, APR_OS_DEFAULT,
> + 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.
Regards,
[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