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>