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.

FFS has an additional problem.  Using FFS (like mfs does) loses
one important piece of information:  which blocks are not being
used.  The problem here is say I have block n and I use block n
for a file and then block n gets paged out to disk.  I then unlink(2)
the file.  When I create a new file that happens to use block n,
I now must page in block n in order to write it.

Even if block n is not paged out, simply unlink(2)'ing the file
(using memory as a FFS) does not tell me that block n is not being
used, and so if I run out of main memory I may page block n out to
disk where I don't actually need to waste time doing so.

And ignoring paging out of block n, block n's existence (not
referenced) may cause another unrelated bit of memory to be paged
out in preference to block n.

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.

This strategy is quite a different beast than layering FFS over a
chunk of memory, but has a number of improvements in speed.

 == Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/  ==
 == The Unofficial NetBSD Web Pages        http://www.Imrryr.ORG/NetBSD/  ==
 == The NetBSD Project                            http://www.NetBSD.ORG/  ==