Date: Tue, 12 Sep 2000 23:55:52 -0400 (EDT) From: Erez Zadok <ezk@cs.columbia.edu> To: Boris Popov <bp@butya.kz> Cc: Terry Lambert <tlambert@primenet.com>, freebsd-fs@FreeBSD.ORG, dillon@FreeBSD.ORG, semenu@FreeBSD.ORG, tegge@FreeBSD.ORG Subject: Re: CFR: nullfs, vm_objects and locks... (patch) Message-ID: <200009130355.XAA23270@shekel.mcl.cs.columbia.edu> In-Reply-To: Your message of "Tue, 12 Sep 2000 08:29:14 %2B0700." <Pine.BSF.4.10.10009120819090.34816-100000@lion.butya.kz>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.10.10009120819090.34816-100000@lion.butya.kz>, Boris Popov writes: > On Mon, 11 Sep 2000, Terry Lambert wrote: > > > > The first one, is an inability to handle mmap() operation. This > > > comes from the VM/vnode_pager design where each vm_object associated with > > > a single vnode and vise versa. Looking at the problem in general one may > > > note, that stackable filesystems may have either separated vm_object per > > > layer or don't have it at all. Since nullfs essentially maps its vnodes to > > > underlying filesystem, it is reasonable to map all operations to > > > underlying vnode. > > > > I had a similar approach, which uses only one additional call: > > > > struct vnode *VOP_FINALVP(struct vnode *vp); > > Three separate calls provide explicit and clear create/use/destroy > paradigm (it is somewhat broken by VFS but can be solved in future). > > > My approach, and the one you have put forward, are both flawed, if > > you try to move beyond the simple case of a 1:1 correspondance > > between stacking layers and underlying objects. > > They're not flawed, but require complex layers to implement its > own VOP_GETPAGES/PUTPAGES operations. IMO, there can be more than one VM > backing object in the stack, so any layer which performs data conversion > tasks or gather data from multiple underlying filesystems can provide > its own VM object to keep coherency between mmap() and read/write > operations. On some point support routines can be integrated into VFS > code. Cache coherency issues is just one angle. Do either proposals handle fan-out file systems, where may be more than one backing VP? IMHO if we're changing the VFS, might as well have support for custom page coherency schemes, fan-in, fan-out, etc. Erez. 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?200009130355.XAA23270>