[darcs-users] Re: [OpenAFS] Re: afs semantics

[Jeffrey Hutzelman]

On Sun, 11 Jun 2006, Juliusz Chroboczek wrote:

> Thanks for the information, Jeffrey.
>
> >>   2. If two processes both attempt to rename() the same [source] file,
> >>      does AFS guarantee that exactly one of them succeeds?
>
> > It should.
>
> And what about link(2)?  It is my understanding that link(2) on
> OpenAFS works fine as long as the link remains in the same directory,
> right?

Yes.

> If that's the case, is link atomic in the same sense as rename above?

Link is atomic, but not in the same way as rename.  What I'm about to
describe should already be familiar to you....


If a process attempts to use link, symlink, mkdir, open(O_CREAT|O_EXCL),
etc to create a file that already exists, the operation will fail.  If
multiple processes try to do that to the same file, then the two
operations will be serialized with respect to the target directory at the
fileserver, and at most one will succeed.  It's possible for all the
simultaneous operations to fail, but not for all of them to fail with
EEXIST, unless the file already existed.

Similarlty, if a process attempts to rename or unlink a file that doesn't
exist, the operation will fail.  If multiple processes try to do that to
the same file, at most one will succeed.  Again, they can all fail, but
they shouldn't all fail with ENOENT, unless the file really didn't exist.

It is worth pointing out here that rename is actually atomic; there is no
point visible to clients at which neither name works, and there is also no
point at which both names reach the same file (assuming that wasn't the
case before the rename).  It seems possible for a client to violate the
latter property, depending on how the OS works, but I haven't reviewed
that code.  AFS also tries to provide the property that if the new name
existed before the rename, there is no point at which it does not exist.
It is possible for the operation to fail in such a way that the new name
no longer points to any file, but not in normal operation -- such a
failure would indicate a corrupted directory or some sort of I/O error.

Rename does not have the same property as link, etc with respect to the
target name - the operations are serialized, but you can rename over an
existing target, so if the rename comes second, both operations succeed.

-- Jeff