[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:
> I'm not convinced it's worth putting ufs_rename in its own file.
> Despite the huge block comment, my version is quite a bit shorter than
> the previous version. :-)
> The separate wapbl copy should just be killed entirely.
While it may not be that big, I do not see the reason why not to put
ufs_rename() with ufs_parentcheck() and ufs_checkpath() helpers into
a separate file. It would be easier to read and work with code.
> We have some, and I have some others that I need to find time to
OK, we should have a list of tests covering as much cases as one can think
of i.e. let's do some quality assurance. :)
> > Hmm, that is slightly confusing. Since fromparent_vnode was unlocked, is
> > there anything who prevents from other thread doing, let's say, rename on
> > "old" a_tvp, and creating a hardling to fromchild_vnode in
> > tochild_vnode's path? If not (unless you serialize entire ufs_rename(),
> > but that is not what we want), following relookup() will lock against
> > oneself.
> It is what we want; there's only one rename at a time per volume. This
> is necessary for at least two other major reasons. (Go reread the big
> block comment. :-) )
No, not in the long term, or let me rephrase it. The current form of heavy
per-mount rename lock significantly reduces concurrency and we already can
notice that in the lockstat.
Without major locking revamp, I wonder if we can use hashed-locks based
on parent vnodes for rename serialisation? Something for mid-term.
P.S. Regarding big comment - please make it shorter, it is easier to me
to just read the code (both ufs_rename and sys_rename) right now. :)
Main Index |
Thread Index |