gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: [BUG] FEATURE PLANS: revlib locking


From: Jan Hudec
Subject: Re: [Gnu-arch-users] Re: [BUG] FEATURE PLANS: revlib locking
Date: Fri, 4 Jun 2004 14:45:51 +0200
User-agent: Mutt/1.5.6i

On Fri, Jun 04, 2004 at 14:37:42 +0200, Juliusz Chroboczek wrote:
> >> Now the only way to break atomicity is, that the kernel would
> >> temporarily create the entry even if it's going to return failure and
> >> remove it again. I don't think any kernel would do such useless work.
> >> I also think, that atomicity of link(2) is part of POSIX.
> 
> AS> NFS does not attempt to support POSIX filesystem semantics. It's just
> AS> a convincing facsimilie. 
> 
> No, but it does have relatively well-defined semantics (CTO consistency).
> A link operation is atomic under both NFSv2 and NFSv3; the problem, is
> that the result is not reliable: in case of retransmission, you could
> receive EEXIST although the operation was successful.

That's why the original post talked about reading link count of nonce
(temporary file with unique name). If clients try to create links to
different inodes, reading the link count will tell which one succeeded.

> Another thing to be aware of is that open(O_EXCL) is not atomic with
> NFSv2 (it is with NFSv3).

In Linux it is NOT, at least in 2.4 (not looked in 2.6), because in
Linux 2.4, the O_EXCL flag is simply not passed to the filesystem
driver.

> And of course the network can be hit by a nuclear strike at any time.
> With a soft mount, this means that any NFS request (including link)
> can get an EIO with no indication of success or failure; with a hard
> mount, it means that your application could hang at any point.
>
> Jan's suggestion is perfectly reliable with a hard NFS mount (hangs
> aside).  Using open(O_EXCL) to implement locks is perfectly reliable
> with a hard NFSv3 mount.

No, the suggestion (I am not the original poster, I just defend it) is
reliable with link and soft mounts. If I get EIO, I just restart the
link call.

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]