On 2006-08-07, Matthew Dillon <[EMAIL PROTECTED]> 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
