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

[Jan Hudec]

On Fri, Jun 04, 2004 at 13:07:50 +0100, Andrew Suffield wrote:
> On Fri, Jun 04, 2004 at 12:47:23PM +0200, Jan Hudec wrote:
> > Only atomicity I want is atomicity of the underlaying syscall!
> > 
> > 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.
> 
> NFS does not attempt to support POSIX filesystem semantics. It's just
> a convincing facsimilie. Deal with it. POSIX filesystem semantics are
> not convinient for a network filesystem; I'm not actually aware of any
> that attempt to implement them.

No. But it uses the underlaying syscalls, that have the properties and
the server has no reason to break it.

On the other hand, when I try to imagine Windows NFS server...

I still don't see a reason why any implementation should not do the
right thing, in this particular case (not talking generaly -- they are
doing many wrong things). Most probably it's not specified, however.

> > Now the only way for the NFS server to break this would be to do the
> > same useless work -- create the link, then check if it should do it and
> > delete it again if it shouldnt. In addition to being a bug, it's SO much
> > extra work (when you can just do the syscall and see), that I don't
> > think any NFS server breaks this.
> 
> You think wrong. Here's a specific counterexample along the lines you
> describe:
> 
> The server creates the link, sends the RPC reply saying that the link
> was created, and the reply gives an EHOSTUNREACH message. Just to make

But I do not care for the return value of the link request! I just drop
it on the floor!!!

> things even more fun, you now have a link and two clients which think
> it's not their lock. You can spend weeks chasing the corner cases, but

No. The clients check link-count on their respective temporary files.
Since it will be a link to one of them, one of the clients will,
eventualy, get reply saying 2. That client knows it has the lock and
goes ahead. The other equaly well knows the resource is not available.

> you'll just discover that *NFS IS NOT ATOMIC*, which is what everybody
> has known all along.

No, nfs is not atomic. I knew that all along ;-). But I am saying, that
it's sufficient if the UNDERLAYING FILESYSTEM on the server has atomic
link.

> It's just one of many. Nothing is simple with a connectionless RPC
> system.

That's none. What are the others?

Btw: Connections don't win you anything. It's simply a problem, that no
network can make sure something is delivered exactly once. At most once
or at least once. So you'd need operations to be idempotent. But
operations like this are not.

> > > > And no resolution is perfect.
> > > > It simply can't be, because you never know for sure whether the client
> > > > crashed, or just it's connection died.
> > > 
> > > ...actually, you do. That's what NSM gives you, as supported by
> > > rpc.statd, which is a required component for fcntl() locks over
> > > NFS. It's based on the assumption that clients will get rebooted
> > > reasonably quickly.
> > 
> > ... which may work in few more cases, but does not work generaly.
> 
> Actually it does work in the general case.

But not universaly.

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

signature.asc
Description: Digital signature