[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Move the vnode lock into file systems
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
Main Index |
Thread Index |