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

[Jan Hudec]

On Sun, Jun 06, 2004 at 13:22:25 -0700, Tom Lord wrote:
> [snap]
>
> 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

It actualy does not prevent corruption. If a lock can be broken at any
time, it might so happen, that it's broken halfway during the writeout.
In that case, first half of the change is there and the second is not,
because the lock was broken, and prevented the write to complete.

Since over network, only persistent locks are possible (you can't
relibaly get message about holder's death), the locks must be breakable
(otherwise the stale lock would remain forever).

Now, puting the above two together, you must be able to revert the
changes if the lock is broken. That boils down to 'transactions' -- you
need something, that can be called a 'rollback'.

> [snap]
> 
> 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.

An enforced, persistent lock might be possible another way (I don't
think it is), but as I explained above, you need something stronger --
something that can be viewed as transactions. And the renaming trick
gives you that -- the final rename can be thought of as commit. If it
fails, no changes take effect. And that you need.

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

There is a perl module called File::Transaction::Atomic. It claims to
achieve atomic update spanning several files. The description can be found on:
http://search.cpan.org/~ncleaton/File-Transaction-Atomic-1.00/Atomic.pm#HOW_IT_WORKS

Basicaly it's about making a copy in a temporary directory, making
a symlink to that directory and then changing the actual files to
symlinks going via the first symlink.

Then, in another temporary directory, you prepare the new versions. Then
the actual commit happens by changing the first symlink to point to the
new temporary directory. And last you clean up the links by renaming the
actual files over the symlinks.

You can enforce that only one set of temporaries exist using directory
renaming. That will give you only one transaction running at a time. It
still does not give you a read-lock though.

Note: rename on files replaces the old file, atomicaly. Exceptions are
only directories, that can't be unlinked. This behavior is relied upon.

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

signature.asc
Description: Digital signature