VOP_RENAME of the future

[Csaba Henk]

On 2006-08-07, Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> :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'.

It seems then that I was wrong. I misunderstood the meaning of the lock
flags. I thought LK_RETRY is the way for making the lock acquisition
blocking, and without that the lock acquisition becomes non-blocking 
and thence fallible.

Sorry for arguing based on a confused perception of the concepts
involved.

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

Yes, I know.

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

I see.

Csaba