From owner-freebsd-fs Tue Sep 5 12:42:49 2000 Delivered-To: freebsd-fs@freebsd.org Received: from earth.backplane.com (backplane-inc.SanFranciscosfd.cw.net [206.24.214.242]) by hub.freebsd.org (Postfix) with ESMTP id 045FB37B422; Tue, 5 Sep 2000 12:42:47 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.9.3/8.9.3) id MAA76219; Tue, 5 Sep 2000 12:42:19 -0700 (PDT) (envelope-from dillon) Date: Tue, 5 Sep 2000 12:42:19 -0700 (PDT) From: Matt Dillon Message-Id: <200009051942.MAA76219@earth.backplane.com> To: Boris Popov Cc: "Daniel C. Sobral" , freebsd-fs@FreeBSD.ORG, semenu@FreeBSD.ORG, tegge@FreeBSD.ORG Subject: Re: CFR: nullfs, vm_objects and locks... (patch) References: Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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