Re: Fixing the FSFS corruption bug

Malcolm Rowe <malcolm-svn-dev@farside.org.uk> writes:

>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.

Right. No even remotely modern system lacks rename(2).

>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.

CVS uses a lock directory (empty) instead of a file, arguing that this
is less likely to cause problems with aggressively caching NFS
clients, and because it is always an error to create a directory twice
(no reliance on O_EXCL needed).

While not as theoretically bulletproof as the create-link-stat dance
(because of the replay problem that you noted), it appears to work
well in practice. At least I have never heard of a problem that could
be traced to this.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 12 20:57:43 2006