I did say "enhance FFS this way (and also to call some device hook
when it frees a block)".  the idea being that FFS can easily inform the
underlying device when it's no longer using a given block.  real devices
will ignore this information and this virtual swap-backed device will
convert the page(s) back into zero-fill memory.  (this would work best
if the blocksize was at least as big as the page size, but you'd really
want that anyway so you could eventually do uvm loanout on the pages
when applications read() files).

-Chuck


On Wed, Mar 15, 2000 at 02:00:56AM -0800, 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.
> 
> 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/  ==