From owner-freebsd-fs Tue Sep 12 20:56: 3 2000 Delivered-To: freebsd-fs@freebsd.org Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by hub.freebsd.org (Postfix) with ESMTP id A849F37B423; Tue, 12 Sep 2000 20:55:59 -0700 (PDT) Received: from shekel.mcl.cs.columbia.edu (shekel.mcl.cs.columbia.edu [128.59.18.15]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id XAA27985; Tue, 12 Sep 2000 23:55:56 -0400 (EDT) Received: (from ezk@localhost) by shekel.mcl.cs.columbia.edu (8.9.3/8.9.3) id XAA23270; Tue, 12 Sep 2000 23:55:52 -0400 (EDT) Date: Tue, 12 Sep 2000 23:55:52 -0400 (EDT) Message-Id: <200009130355.XAA23270@shekel.mcl.cs.columbia.edu> From: Erez Zadok To: Boris Popov Cc: Terry Lambert , freebsd-fs@FreeBSD.ORG, dillon@FreeBSD.ORG, semenu@FreeBSD.ORG, tegge@FreeBSD.ORG Subject: Re: CFR: nullfs, vm_objects and locks... (patch) In-reply-to: Your message of "Tue, 12 Sep 2000 08:29:14 +0700." Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , 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