VOP_RENAME of the future

[Csaba Henk]

On 2006-08-07, Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:
>:
>:        if ((error = vn_lock(fvp, LK_EXCLUSIVE)) != 0)
>:	        goto abortit;
>
>     That's pretty much how the BSD's do it, because the old filesystems
>     like UFS require an atomic LOOKUP + OP (e.g. LOOKUP + CREATE,
>     LOOKUP + REMOVE) combination.  UFS stores side effects from the LOOKUP
>     which are then used in the later CREATE/REMOVE/RENAME/SYMLINK/MKNOD/RMDIR,
>     etc.  The vnode must remain locked through both operations.

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?

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

>     I am not intending to do any more work on UFS then I have to.  Any

Understandable...

>     *NEW* VFS ports can just use the new VOP_N*() calls and not implement
>     the old junk at all.
>
>     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