Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Sep 2000 12:42:19 -0700 (PDT)
From:      Matt Dillon <dillon@earth.backplane.com>
To:        Boris Popov <bp@butya.kz>
Cc:        "Daniel C. Sobral" <dcs@newsguy.com>, freebsd-fs@FreeBSD.ORG, semenu@FreeBSD.ORG, tegge@FreeBSD.ORG
Subject:   Re: CFR: nullfs, vm_objects and locks... (patch)
Message-ID:  <200009051942.MAA76219@earth.backplane.com>
References:   <Pine.BSF.4.10.10009052108550.81844-100000@lion.butya.kz>

next in thread | previous in thread | raw e-mail | index | archive | help
    I agree with all of Boris's points in regards to the two major changes: 
    Adding VOP's to access the VM object, and integrating the vnode lock
    into the vnode directly.

    There is one issue which needs to be resolved, and that is with NFS.  It
    is not safe to lock vnodes related to NFS, which is why the NFS VOP locking
    routines always force shared locks.  This problem would have to be 
    resolved.

    About a year ago I attempted to make NullFs work with mmap().  I did it
    by overloading one VM object on top of another... essentially creating
    two vnode-backed VM objects.  I was never able to get this to work 
    properly because a huge amount of kernel code assumes that a VM object
    of type OBJT_VNODE is always a leaf.  Boris's way of doing the stacking
    should be much more stable and considerably easier to maintain.

    Boris's patches look good, though I didn't go over them with a fine-toothed
    comb.  I'm amazed at how clean the nullfs changes are with the new
    infrastructure there to support it.

    This patch involves architectural changes so I think either DG or Kirk 
    have to sign off on it (maybe more Kirk then DG for this since it is
    filesystem related).  I think Kirk will agree with it assuming the NFS
    issue can be dealt with.

						-Matt

:On Tue, 5 Sep 2000, Daniel C. Sobral wrote:
:
:> >         The simple solution for it is to integrate lock structure into
:> > vnode and making vnode.v_vnlock initially point to it. Any filesystem
:> > above can pickup the pointer and assign it to v_vnlock field in its own
:> > vnode structure. If underlying filesystem doesn't provide any lock
:> > structure then bad times are coming and each layer can maintain its own
:> > lock state.
:> 
:> How can it handle fs multiplexing? Ie, a single underlying layer with
:> multiple non-stacked layers above?
:
:	Just like in the stacking case: access to vnode on the underlying
:filesystem should be serialized which is done by proper(shared) locking.
:
:--
:Boris Popov
:http://www.butya.kz/~bp/



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009051942.MAA76219>