tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Layered fs, vnode locking and v_vnlock removal

On Tue, Jun 01, 2010 at 01:54:53AM +0000, David Holland wrote:
> On Sun, May 23, 2010 at 04:11:25PM +0200, Juergen Hannken-Illjes wrote:
>  > With our current vnode lock implementation VOP_LOCK() and VOP_UNLOCK()
>  > are not symmetric.  A vnode may be locked from one file system and
>  > unlocked from another one.  Is there any reason left to have layered
>  > file systems share the vnode lock with lower file systems via v_vnlock?
>  > 
>  > The attached patch will remove v_vnlock and change layered file systems
>  > to always pass the locking VOP's down to the leaf file system.
> I'm not sure. This is fine for things like umapfs and nullfs where
> there's a 1-1 mapping between upper and lower vnodes; but what if
> there isn't? Consider for example a versioning FS layer that stores
> versions as diffs, or a layer that turns /var/mail into maildirs. It's
> not immediately clear how either of these ought to work, so I'm
> concerned that making the infrastructure less general will lead to
> problems.

1) One upper to many lower vnodes
   This is a file system like unionfs.  It has to lock either one or
   many lower vnodes and does/will not earn anything of shared locks.

2) Many upper to one lower vnode
   Such a layered file system could use a lock shared between ALL
   upper and the lower vnode.  Always taking the lower vnode's lock
   will do the same.  I see no need for shared locks here.

> In the long run I intend to make all the vnode ops symmetric with
> respect to locking, which should make a lot of this less toxic, but at
> the rate I've been able to work on this stuff we won't be there
> anytime soon.

The asymmetry comes from functions like null_mount() where a vnode gets
locked by the lower layer and unlocked by the upper layer.  A lower
layer expecting its VOP_LOCK() to be matched by a VOP_UNLOCK() will
fail badly.

In the long term VOP_xxxLOCK() should become part of the file systems.

> -- 
> David A. Holland

Juergen Hannken-Illjes - - TU Braunschweig 

Home | Main Index | Thread Index | Old Index