Date: Fri, 2 Oct 1998 02:33:42 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Terry Lambert <tlambert@primenet.com>, Don.Lewis@tsc.tdk.com (Don Lewis) Cc: freebsd-fs@FreeBSD.ORG Subject: Re: vm system interaction with nullfs Message-ID: <199810020933.CAA15261@salsa.gv.tsc.tdk.com> In-Reply-To: Terry Lambert <tlambert@primenet.com> "Re: vm system interaction with nullfs" (Sep 13, 10:43pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 13, 10:43pm, Terry Lambert wrote: } Subject: Re: vm system interaction with nullfs } > Since the vm system keeps track of what it has in memory by (vnode, offset), } > how is this supposed to work when stackable filesystems are in use which } > create multiple vnodes for a single filesytem object, or is this broken? } } Yes, this is still broken. } } This was the primary reason for the migration of a putpages/getpages } into all "bottom-of-stack" FS's. } } The general fix is to create a "getfinalvp". This would allow you } to page through an object, while allowing layers stacked on top to } dictate layout/content. I started down this path and created VOP_GETBACKINGVP. This part was pretty easy. The problem is that there are a zillion references to vp->v_object all over the place that would need to be fixed. } Another part of the puzzle is that the vnode locking is overly } complex (VOP_LOCK). Yes. This is another one of those places where I get lost in a maze of twisty little passages ... } > It would seem that in the case of nullfs and similar transparent filesytems, } > the vm system should always use the lowest vnode, but this doesn't seem to } > be implemented (though I could just be getting lost in the maze of twisty } > little passages). It's even messier if the layer isn't transparent, } > like an encryption layer. } } Not in all cases, actually. For a cryptographic FS (such as the } one one of John Heidemann's students wrote, and John sent me), you } will want a backing object for the unencrypted data, seperate from } the backing object of the on-disk data. } } There are also cases where the in-core data and the backing data } aren't the same size. For some of these (like a compression layer), } you would implement this via the comperssion layer's vp's get/putpages, } and not operate on the backing store directly. It looks like some clues to how to properly implement this are in the paper you mention. } Really, you should go to ftp.cs.ucla.edu, and read up on the } stacking architecture. The documents in the "ficus" directory } are the actual design documents for the BSD 4.4 stacking } architecture. Got it. I thought I'd read this paper before (a year or so ago), but apparently I had snagged an earlier version. The lastest one, UCLA-CSD-950032, is much more complete. Unfortunately, I only managed to read the first quarter before being distracted by other fires. My immediate needs don't require the full functionality of stackable filesystems, or even all that nullfs is capable of. I really need to finish reading this paper so I can find out if featherweight layering meet my requirements, since that might be easier to get working. 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?199810020933.CAA15261>