Re: tstile syndrome

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> 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.

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.
(i'm not talking about zfs, which i'm not familiar with.)

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.

YAMAMOTO Takashi