VOP_RENAME of the future
csaba.henk at creo.hu
Mon Aug 7 15:16:34 PDT 2006
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
> 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.
More information about the Kernel