gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrew Suffield
Subject: Re: [Gnu-arch-users] Re: [BUG] FEATURE PLANS: revlib locking
Date: Thu, 3 Jun 2004 23:31:38 +0100
User-agent: Mutt/1.5.6i

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

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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]