Re: locking patches for ufs_rename

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

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

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

-- 
Mindaugas