[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: tstile syndrome
> On Thu, Sep 24, 2009 at 06:05:47AM +0000, YAMAMOTO Takashi wrote:
> > > But I have two things to say: (1) locking a per-vnode lock directly is
> > > no different from calling vn_lock() -> VOP_LOCK() to lock a per-vnode
> > > lock, and this appears to be what the rename logic does; and (2) while
> > > it isn't cut-and-pasted all the lock-handling code for rename is
> > > exactly an example of what ought to be fs-independent.
> > parent-to-children order vnode locking is one of things which
> > complicate our rename. inode-number order locking can simplify it
> > because it's easier to lock multiple inodes in that way.
> Only if you're willing to make heavy use of relookup() and run the
> risk of subtle concurrency issues. If the number order is such that
> you have to unlock the parent before locking the child, then you
> aren't atomic any more, and relookup is at best a band-aid for that.
what kind of atomicity are you talking about here?
sure, we need to ensure that the files are still in the expected state
> To the best of my knowledge there's only one way to do rename
> correctly. (Two if you count doing strict two-phase locking.)
can you please explain a bit more about "correctly"?
> > besides that, the assumption that all filesystems need the same
> > cut-and-pasted locking is wrong. there are filesystems which have
> > fundamentally different locking requirements. nfs is an obvious example.
> Yes and no. Most of the locking requirements and locking structure
> arises from the atomicity semantics of the system calls. That's
> fs-independent. Even with nfs's creative consistency model you still
> need e.g. the logic that makes O_EXCL (locally) atomic.
> Anyhow, it's not cut-and-paste of locking as such that concerns me so
> much as cut-and-paste of things like the O_EXCL code, which is
> security-critical. Maybe it can be done in genfs; however, that would
> probably just end up trading VOP_LOCK() for gop_lock(), which is not
> an improvement.
O_EXCL isn't a good example because nfsv3 can handle it remotely.
> David A. Holland
Main Index |
Thread Index |