Date: Mon, 5 Mar 2001 17:44:25 -0800 From: Jim Browne <jbrowne@jbrowne.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: "Michael C . Wu" <keichii@iteration.net>, freebsd-small@FreeBSD.ORG, "Forrest W. Christian" <forrestc@imach.com> Subject: Executing no-copy from md(4) devices (Was Re: Sans-Swap VM Subsystem Questions) Message-ID: <v04205512b6c9b0e8beb9@[216.39.8.88]> In-Reply-To: <200102120610.f1C6AfO02706@earth.backplane.com> References: <Pine.BSF.4.21.0102111925480.22351-100000@workhorse.iMach.com> <200102120610.f1C6AfO02706@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04205512b6c9b0e8beb9>