VOP_RENAME of the future
dillon at apollo.backplane.com
Mon Aug 7 10:11:30 PDT 2006
: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
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
:), because it will have to stay very generic and that won't allow the
:"prelude" like steps to be done at the VFS level?
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.
<dillon at xxxxxxxxxxxxx>
More information about the Kernel