[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: tstile syndrome
On Sun, Sep 13, 2009 at 11:34:16PM +0200, Adam Hamsik wrote:
>>> Not true at all. In Mac OS X, there is no exposed vnode-level
>>> at the VFS layer or in the VFS<->file system interface. Everything
>>> handled at the lower layers.
>> How does this simplify the hard problems (vnode recycle, rename,
> I think that ZFS is nice example how rename can be handled look at
Well, I see several likely races in there and probably at least one
locking order violation in rename, but I haven't examined it closely
enough to say for sure one way or the other. It's no worse than the
current ufs_rename, anyway.
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.
>> Also, how does it work with layers? And how do you make atomic
>> create/mkdir work correctly?
Also, as far as I can tell, the zfs code for mkdir and create does
contain its own private copy of the fs-indepenent exclusivity logic.
> I think that you should provide working example, because AFAIK current
> locking scheme doesn't work e.g. unionfs.
Nothing works with onionfs, so that's a moot point. The current scheme
(even with its known problems) does work for things like umapfs.
> Asking others to prove that
> their solution works, when it doesn't work, now doesn't seems right to
> me. In ZFS almost all locking was pushed to the FS level and it works.
Based on twenty minutes' inspection, I'm not at all convinced that it
does work. But that's irrelevant; it's obviously possible to make it
work entirely within the FS if you don't care about layers and you
don't care about duplicating FS-independent logic. The question is if
it's a good idea.
David A. Holland
Main Index |
Thread Index |