tech-kern archive

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

Re: locking patches for ufs_rename



David Holland <dholland-tech%netbsd.org@localhost> 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?  

> 1. It is necessary to deny renames of the form rename("a",
> "a/b/c/d/e/f/g/h/i/j/k/a"),
>
> <...>
> 
> 2. If you have these three renames running concurrently:
>    rename("a/b", "c/d");
>    rename("c/d", "e/f");
>    rename("e/f", "a/b");

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.

-- 
Mindaugas


Home | Main Index | Thread Index | Old Index