Re: Move the vnode lock into file systems

[Juergen Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost>]

On Sun, Jun 27, 2010 at 02:06:31AM +0000, David Holland wrote:
> On Sat, Jun 26, 2010 at 10:39:27AM +0200, Juergen Hannken-Illjes wrote:
>  > The vnode lock operations currently work on a rw lock located inside the
>  > vnode.  I propose to move this lock into the file system node.
>  > 
>  > This place is more logical as we lock a file system node and not a vnode.
>  > This becomes clear if we think of a file system where one file system node
>  > is attached to more than one vnode.  Ptyfs allowing multiple mounts is such
>  > a candidate.
> 
> I'm not convinced that sharing locks at the VFS level is a good idea
> for such cases. While ptyfs specifically is pretty limited and
> unlikely to get into trouble, something more complex easily could. I
> don't think we ought to encourage this until we have a clear plan for
> rebind mounts and the resulting namespace-handling issues. (Since
> in a sense that's the general case of multiply-mounted ptyfs.)
> 
> Since I'm pretty sure that a reasonable architecture for that will
> lead to sharing vnodes between the multiple mountpoints, and
> manifesting some kind of virtual name objects akin to Linux's dentries
> to keep track of which mountpoint is which, I don't see that it's
> necessary or desirable to specialize the locking...
> 
> Do you have another use case in mind?
> 
> (In the absence of some clear benefits I don't think it's a
> particularly good idea to paste a dozen or two copies of genfs_lock
> everywhere. But folding vcrackmgr() into genfs_lock and genfs_unlock
> seems like a fine idea.)

Primary goal is to abstract vnode locking into the vnode operations
only and therefore completely removing vlockmgr().

For now I can live with genfs_lock()/v_lock becoming the generic
locking interface where v_lock becomes genfs_lock()-private.

-- 
Juergen Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig 
(Germany)