Apologies for the diversion into obscure Unix and NFS semantics. It's
important for my back-end design. Nothing specific to Subversion here,
though, so busy developers can ignore us.
On Sat, 2002-06-08 at 17:46, Stephen C. Tweedie wrote:
> > * rename() is both failure-atomic and concurrency-atomic; either the
> > rename has happened or it hasn't.
I didn't mean to imply that rename() was asynchronous when I said it was
failure-atomic. But apparently the claim was still a bit too strong.
> BSD-style Unixen do guarantee that a crash will never leave the inode
> in a deleted state --- ie. a crash at an inopportune moment may leave
> both the old and the new directory entry present, but the disk will
> never see the old entry deleted before the new one is created.
This is what I really meant; the case where both the old and new
directory entries exist isn't usually all that important.
> Also, some of the more async Unix filesystems don't even guarantee
> that relaxed form of failure atomicity
You mean that a failure could leave the target directory entry
nonexistent? I'm curious which filesystems have this property. (I
assume you're not counting things like FFS with the async flag set; such
combinations are documented with big red flags as being unsafe.)
> but you can always simulate
> that by using a combination of link(2) and fsync(2).
If I'm not mistaken, fsync()ing a directory is a very Linux-specific
concept. So if there are any non-Linux filesystems which don't provide
the flaxed failure atomicity guarantee, I'm not sure how one would
simulate it.
(Also, link() fails when the target exists. How would you use it to
emulate relaxed-failure-atomic rename?)
> > (Some of these guarantees degrade or disappear for remote filesystems,
> > particularly some vintages of NFS. I don't know all the details
> > there.)
> I can help on the details if you want.
Is rename() any less concurrency-atomic or failure-atomic than with
local filesystems?
> Most NFS systems will offer
> decent fcntl() locking these days, for example, and there are already
> libraries in existance (used for things like mailbox locking) to
> emulate NFS locking via atomic creation of temporary lock files on
> those systems where fcntl() does not work.
I'm still not sure how to create a lock in older NFS implementations, if
it's even possible. fcntl() locking will work in some implementations
but not others. open() with O_EXCL won't work in NFSv2. (Lots of lore
on the net to corroborate this.) A google search yields suggests:
* Create a temporary file with a unique name.
* link() it to the lock file name.
* Check to make sure your temporary file has a link count of 2.
I'm not sure why this would work any better than open() with O_EXCL,
unless link() is atomic (in which case why bother with the third
step?). The following sequence seems like it would make the above
algorithm fail:
Client 1: Create temporary file
Client 2: Create temporary file
Client 1: Link to lock file
Client 1: Check link count
Client 2: Link to lock file and succeed due to non-atomic link()
Client 2: Check link count
Perhaps there's something else going on here; perhaps a non-atomic
link() success can't happen when there's been an intervening request (in
this case, client 1's checking of the link count).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 9 23:22:53 2002