On Mon, Sep 11, 2006 at 09:06:13PM +0100, Philip Martin wrote:
> I suppose you might be able to use some sort of rename system instead
> of using a separate lock file: rename the file before writing it and
> then rename it back when the write is complete. An incomplete write
> would leave the renamed file which a subsequent write would need to
> delete.
>
I _think_ that should work, but I'm a little hesitant to use a different
locking mechanism to the one we're already using, particularly as I
don't have any way to test on NFS.
There are also issues with rename on NFS, though perhaps none that we
need to worry about. For example, rename() only guarantees atomicity if
the underlying OS supports a rename() syscall (as I imagine that all do,
nowadays); previously, this was emulated using a link()/unlink() pair.
Another example: as rename() isn't idempotent, a replayed request can
lead to the rename() returning failure even though the original request
actually succeeded. So you're supposed to check whether the file exists
after you rename, and assume it succeeded if so, it seems.
Probably these are merely theoretical concerns, and perhaps using rename()
to create a lockfile over NFS would work fine (though it doesn't seem
like anybody else is doing it)... but without any way to be sure, I think
I'll stick with the fcntl/mutex approach used for the fs-wide write-lock,
even if it is slightly more code.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 12 19:49:49 2006