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

[Andrew Suffield]

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:
> > On Thu, Jun 03, 2004 at 08:11:41PM +0000, Julian T. J. Midgley wrote:
> > > In article <address@hidden>,
> > > Andrew Suffield  <address@hidden> wrote:
> > > >-=-=-=-=-=-
> > > >-=-=-=-=-=-
> > > >
> > > >On Sat, May 29, 2004 at 02:14:39PM +0100, Andrew Suffield wrote:
> > > >> But if you want to support almost any other combinations of
> > > >> anything then you're screwed.
> > > >
> > > >Oh, and hint: it is not without good reason that expansions such as
> > > >"Network Failure Service", "No File is Safe", became popular.
> > > 
> > > I understood that 
> > > 
> > >  1. Create nonce file 
> > >  2. hardlink lock file to it
> > >  3. check reference count of nonce file 
> > > 
> > > Was a reliable way of locking files across NFS.  Is this not the case?
> > 
> > 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
probably provides it. In general, "NFS never makes _any_ atomicity or
ordering guarantees". You also have to deal with the fact that the
majority of NFS implementations currently deployed are just plain
broken.

NFSv4 is rather better in this respect, but it's also a non-stupid
network filesystem, so it will be years before you see a reliable
implementation, or one which works between anything other than linux
clients and solaris servers.

> > trying and failing, so you have to rely on random wait states to break
> > this loop. This can be quite impressively slow.
> > 
> > It also requires manual intervention to break stale locks safely.
> > 
> > Neither flock() nor fcntl(), when they work, have these issues.
> 
> Any locking has problems with stale locks.

Well, flock() obviously doesn't. fcntl() also works better than you
suspect because...

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

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

signature.asc
Description: Digital signature