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

[Juliusz Chroboczek]

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

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

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.

AS> NFSv4 is [...] a non-stupid network filesystem,

NFSv4 has nothing to do with NFS, though.  It's related to SMB more
than NFS.  (No comments about NFSv4' alleged non-stupidity.)

AS> POSIX filesystem semantics are not convinient for a network
AS> filesystem; I'm not actually aware of any that attempt to
AS> implement them.

Sun's Network Disk.

                                        Juliusz