"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
> used.

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?

Simon.