Re: VOP_RENAME of the future

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Mon, Aug 07, 2006 at 03:11:40PM +0000, Csaba Henk wrote:
> On 2006-08-07, Matthew Dillon <dillon@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?

The reason why this request can fail if fvp is already locked by the
current process or e.g. a bad filesystem error occured (like an IO
error). This is not about a different processes taking the lock in
between, since vn_lock just blocks for that.

> 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?

The current UFS code is complicated, since it didn't have a separation
between namespace locking and content locking. When you kill the whole
relocking dance, it becomes much simpler. Noone wants to really clean
the UFS locking though, because the code base is extremely complicated.

Joerg