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

[Jan Hudec]

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. Once it is actualy tried on server, it must either
succeed for some client, or return permanent errors (ENOENT, EACCESS) to
all of them. It may return EEXIST to all of them (reply did not arrive
and retry must have obviously failed), but the link-count is what tells
whether it succeeded, provided the temporary file really has unique
name.

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

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

signature.asc
Description: Digital signature