Re: tstile syndrome

[David Holland <dholland-tech%netbsd.org@localhost>]

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  
>>> locking
>>> at the VFS layer or in the VFS<->file system interface.  Everything  
>>> is
>>> handled at the lower layers.
>>
>> How does this simplify the hard problems (vnode recycle, rename,
>> etc.)?
>
> I think that ZFS is nice example how rename can be handled look at  
> zfs_rename.

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
dholland%netbsd.org@localhost