Re: locking patches for ufs_rename

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Oct 29, 2009 at 10:14:08PM +0000, Mindaugas Rasiukevicius wrote:
 > > > Without major locking revamp, I wonder if we can use hashed-locks based
 > > > on parent vnodes for rename serialisation?  Something for mid-term.
 > > 
 > > That will not work. I'd recommend that before you start proposing
 > > alternatives to that lock you understand what it's does. I believe the
 > > big block comment describes it adequately, but just in case not:
 > 
 > By hashed-locks I meant locking two (or one, if hash(v1) ==
 > hash(v2)) locks for both source and destination.  These
 > hashed-locks would have different lock order, c.f. spc_dlock().  It
 > would prevent from the case (1) and probably (2), would not it?

I don't see how. More detail?

If someone does rename("/x", "/a/b/c/d/e/f/g/h/i/j/k/x"), the parent
check has to inspect each one of those intermediate directories. Then,
once it's done so, something has to make sure none of those
directories get modified until the rename is complete.

There are two ways to do that with locks: lock them all and hold all
the locks until rename finishes (that is, two-phase locking) or use
one big lock. Locking them all is likely to be worse for concurrency
than using the big lock, because it locks out not just renames but
*all* operations. Locking them all also violates the established vnode
locking order and would require retooling the entire system.

I don't see any way a hashing scheme can accomplish this.

 > Solaris had a global rename lock too.  They replaced it, at some point, with
 > many try-locks and re-check-state/restart-everything-again dances. It covers
 > at least case (1), not sure about other races.  Of course, this way is ugly
 > and complicated, but unfortunately.. all rename() is quite depressive.

Well, they think it does. Unfortunately, the code in our zfs import
that I looked at the other day is wrong and has a bunch of deadlock
cases. (I dunno how closely it reflects what's in Solaris, but I
suspect it hasn't been changed around that drastically.)

Such complicated schemes are never a good idea anyway.

As I've said before, I think the solution to the global rename lock
issue, when/if it becomes clear that it's a real issue, is to use some
timestamping as well as locks.

-- 
David A. Holland
dholland%netbsd.org@localhost