Re: VOP_RENAME of the future

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Well, it's OK that fvp has to be locked, but giving up when the first
:lock attempt fails looks poor to me. Isn't it just gambling that someone
:else won't take the lock between entering ufs_rename() and trying to
:lock fvp?

    I'm not sure what bit of code you are looking at here.  If one thread
    locks a vnode a second thread trying to lock the same vnode will simply
    block.  A failure occurs only if the first thread destroys the vnode,
    for example if one program does a 'rm A' while another is trying to do
    a 'mv A B'.

:Or you mean that the locking patterns used by ufs/BSD VFS implies that
:there is no safety here?

    I need to know what bit of code you are talking about.

:>     As part of the clustering and userland VFS work I may remove the high
:>     level vnode locking requirements for nearly all the VOP ops, but all
:>     that means is that most of the filesystems (e.g. UFS) would have to do
:>     the locking internally, themselves.  It isn't really removing any 
:>     locking, it would just move it into the VFS so we don't hold exclusive
:>     locks on vnodes over remote VFS's or userland VFSs that could otherwise
:>     deadlock the entire machine.
:
:Do you mean that Dfly's VFS will never let its filesystems' rename look
:as nice and compact as, eg., ext_rename() of Linux does (see
:
:http://sosdg.org/~coywolf/lxr/source/fs/ext2/namei.c#L291
:
:), because it will have to stay very generic and that won't allow the
:"prelude" like steps to be done at the VFS level?
:
:Csaba

    This is apples and oranges.  The *VFS* interface for NRENAME is very
    clean.  You can't get much cleaner, it only takes three arguments
    (fewer then linux, I might add).  The linux FS code tries to abstract
    an essentially uncacheable directory entry all the way up into the
    kernel, just so it can pass it all the way back down again.  I think
    that is a bad idea.

    The UFS filesystem implementation is a different matter.  Most 
    modifying operations assume that the vnode will not be modified if
    the operation blocks on an I/O, so the vnode has to remain locked
    through the whole operation.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>