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

[Andrew Suffield]

On Fri, Jun 04, 2004 at 12:47:23PM +0200, Jan Hudec wrote:
> On Fri, Jun 04, 2004 at 11:01:01 +0100, Andrew Suffield wrote:
> > On Fri, Jun 04, 2004 at 11:31:48AM +0200, Jan Hudec wrote:
> > > On Thu, Jun 03, 2004 at 23:31:38 +0100, Andrew Suffield wrote:
> > > > FSVO "reliable". It's non-atomic - it is not the case that precisely
> > > > one process will get the lock. Specifically, it's possible that no
> > > > processes will get the lock. If you get two clients trying to claim
> > > > the lock at once, they can get into a mutual busy loop, repeatedly
> > > 
> > > Would you care to explain how can neither process get the lock (provied
> > > they all have appropriate permissions)? AFAICT the link operation is
> > > atomic on the server.
> > 
> > I don't believe that's generally true, although the linux NFS server
> 
> 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.

> 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
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
you'll just discover that *NFS IS NOT ATOMIC*, which is what everybody
has known all along.

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

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

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature