[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: Mattias Engdegård <mattias_at_virtutech.se>
Date: 2006-09-12 20:55:03 CEST

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

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.