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

[Tom Lord]

    > From: Jan Hudec <address@hidden>

    > Any locking has problems with stale locks. And no resolution is
    > perfect.

Sort of, yes, but....

There's a design space for locking mechanisms.   The space is 
characterized by a few questions:

* are the locks advisory or enforced?

  If advisory, a well behaved (non-malicious) program can 
  "accidentally" create unwanted side effects even if its
  lock has been broken.   Programs which rely on advisory
  locks are certainly flaky (they can fail, as a result) but
  might be useful anyway (if the flakiness is a bit unlikely
  and, anyway, relatively inconsequential).

  If enforced, then if a lock is broken, the process holding the
  now-broken lock is (normally, unless it takes malicious steps)
  prevented from making any further unwanted side effects.   For
  example, if I were going to "lock a filesystem tree" in order to 
  make changes to it, but halfway through those changes my lock is
  broken, then my next `write(2)' call into that tree should fail.


* are the locks persistent? or coextensive with the lock-holding process?

  If locks are persistent then (a) a lock-holding process can die 
  but the lock be left held (stale lock) and (b) a lock can be broken
  without any reliable signal being delivered to the former
  lock-holder process.

  If locks are coextensive with their processes, then a lock can only
  be broken (or released) by its owner, but any kind of process death
  to the owner counts as breaking all locks held by that owner.



If you want to lock a tree that might be on NFS you will need:

  * an enforced lock that keeps you from modifying the tree if
    your lock is broken

  * a persistent lock because persistency on the filesystem is the
    only channel of communication to peer processes that might
    contend for the lock

We've seen proposed solutions such as linking to a lock file (using
link counts on inodes) and renaming a lock file (using the NFS-safe
guarantees about `rename(2)' for locking).

Both of those, if used for tree locking, _do_ give a persistent lock
but _do_not_ give an enforced lock.  Consequently, it will be fairly
easy for processes to wind up trashing trees when the lock files go
astray.

As nearly as I can tell, the only kind of tree-locking you can get in
NFS-world which is both enforcable and persistent is to base it on
renaming.   That is, processes compete to create a directory of a
given name.   Each may be allowed to think that they hold the lock but
the real test comes with the final `rename'.   If that succeeds, then
the process was correct in believing it held the lock and, by virtue
of the rename, the side effects it wanted to create are in place.

The renaming trick doesn't work too well, though, when you're trying
to lock a tree for "in place" modifications.  I don't know of any
(NFS-safe) locking tricks that do work for in-place tree
modifications.  My hunch is that one could prove formally that none
exist.

-t