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