From owner-freebsd-small Mon Mar 5 17:44:52 2001 Delivered-To: freebsd-small@freebsd.org Received: from spoon.alink.net (spoon-server1-eth.sv.alink.net [207.135.64.249]) by hub.freebsd.org (Postfix) with ESMTP id D272437B718 for ; Mon, 5 Mar 2001 17:44:49 -0800 (PST) (envelope-from jbrowne@jbrowne.com) Received: from [216.39.8.88] (netility88.hq.netility.com [216.39.8.88]) by spoon.alink.net (8.9.3/8.9.3) with ESMTP id RAA08510; Mon, 5 Mar 2001 17:44:34 -0800 (PST) Mime-Version: 1.0 X-Sender: jbrowne@pop.alink.net Message-Id: In-Reply-To: <200102120610.f1C6AfO02706@earth.backplane.com> References: <200102120610.f1C6AfO02706@earth.backplane.com> Date: Mon, 5 Mar 2001 17:44:25 -0800 To: Matt Dillon From: Jim Browne Subject: Executing no-copy from md(4) devices (Was Re: Sans-Swap VM Subsystem Questions) Cc: "Michael C . Wu" , freebsd-small@FreeBSD.ORG, "Forrest W. Christian" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 22:10 -0800 2/11/01, Matt Dillon wrote: > I'm not sure what picobsd is using, but its probably MFS. With MFS every > active page will take up 2x the memory and every inactive page will take > up 1x the memory (verses no memory if your backing store is some native > device, like a flash rom). Compression has the same effect -- if > something is compressed on the filesystem, the system eats dirty memory > uncompressing it (compression is something that used to work with a.out > binaries. I don't think it works for ELF binaries anyway). Matt: I've started looking into the source to try and answer this question, but I figure a note to you and the list will be a bit faster. :) Say I have a system that has a root filesystem on an md(4) device that was preloaded at boot by loader(8). The md(4) image is stored gzip'd on flash (NB: not an IDE flash device, plain old flash) and the original image is too large to keep uncompressed in flash. I would very much like program text to not have to exist in RAM more than once. Currently, I do not see how that can be done since md(4) is acting like a block driver for UFS and its data is apparently copied (via struct buf's?) into the vnode vm_objects. Is there any way for the vnode's vm_object to consist of COW copies of the blocks already in RAM in md's image? Please excuse (and correct) any mistakes in my use of the proper terminology. From my limited understanding of the situation, it seems like I have three options: 1) A single-copy system is possible with the current tools and I just do not understand how to implement it. 2) Write a new version of md(4) that can use a back-end with gzip'd blocks. Write the needed tools to convert a regular md image to an image that is gzip'd block-by-block with perhaps an offset table for indexing into the compressed data. Yucky, but avoids having to duplicate the functionality of UFS. 3) Write a filesystem that is a first class VFS client. (V9FS is perhaps a starting point for what I need?) Any pointers will be greatly appreciated. TIA Jim Browne jbrowne@jbrowne.com "We lost our lease. You lose culture" - sign on SF Arts Comission Bldg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message