Subject: Re: swapfs and uvm.
To: None <firstname.lastname@example.org>
From: Simon Burge <email@example.com>
Date: 03/15/2000 22:10:14
"R. C. Dowdeswell" wrote:
> On 953096532 seconds since the Beginning of the UNIX epoch
> Chuck Silvers wrote:
> >the FFS disk layout is actually pretty decent for use in a swapfs, except that
> >FFS has no notion of being able to grow the underlying device (a swap-backed
> >virtual device in this case) when it runs out of space. one approach would
> >be to enhance FFS this way (and also to call some device hook when it
> >frees a block), and then you'd get swapfs for a very small amount of
> >additional work. also, this would pave the way for on-line growing of
> >disk-backed FFS filesystems.
Two comments here:
* Unless we do something like mmaping the aobj to userland (and ending
up with a horribly complicated mount procedure), we'd also need a
full-blown mkfs in the kernel too. Granted my original idea would
also require building a filesystem in the kernel too, but I was
thinking of something a little simpler than FFS. If we just go for
something like the current mfs but implemented on an aobj we will
also hit a lot of pages as all the cylinder groups are set up. If we
do have an in-kernel mkfs, this could be worked around by keep track
of which c/g's have been formatted and which haven't.
* I was planning on creating a aobj of a set size and not worrying
about growing/shrinking it. Adding grow/shrink abilities to FFS was
a little beyond what I was thinking :-)
> FFS has an additional problem. Using FFS (like mfs does) loses
> one important piece of information: which blocks are not being
I think this is what Chuck meant by "and also to call some device
hook when it frees a block".
> I think that what one really wants here is something along the
> lines of what Solaris which IIRC is that files in the tmpfs live
> in the buffer cache (avoiding a bcopy to get it in the buffer cache
> which our mfs requires, and duplicating data thereby wasting memory)
> and are paged out to disk when so required.
As I understand it now, there's no way to say "don't put this block
in the buffer cache" - the current filesystem model revolves around
I/O to buffers only, right? Is this something that will be more
easily addressed with UBC?