Date: Tue, 12 Sep 2000 08:29:14 +0700 (ALMST) From: Boris Popov <bp@butya.kz> To: Terry Lambert <tlambert@primenet.com> Cc: freebsd-fs@FreeBSD.ORG, dillon@FreeBSD.ORG, semenu@FreeBSD.ORG, tegge@FreeBSD.ORG Subject: Re: CFR: nullfs, vm_objects and locks... (patch) Message-ID: <Pine.BSF.4.10.10009120819090.34816-100000@lion.butya.kz> In-Reply-To: <200009112155.OAA18763@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > P.S. Two hours ago Sheldon Hearn told me that Tor Egge and Semen Ustimenko > > worked together on the nullfs problem, but since discussion were private I > > didn't know anything about it and probably stepped on their to toes with > > my recent cleanup commit :( > > The code which I have seen on this subject works using the explicit > coherency synchronization between backing objects. Unlike the approach > in your patches, there is a duplicate backing object. It was my Yes, I've looked at original Semen's patches posted to -current and they provide only "one way" cache coherency. -- 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?Pine.BSF.4.10.10009120819090.34816-100000>