I was thinking of mounting the MFS over / with unionfs so that I wouldn't
have to do any symlink nonsense. It looks simple enough in principle; the
two questions that came to mind were:

1. Is unionfs stable enough for this?

2. How does one mount an MFS (which has no node in /dev) over / with unionfs?

As for the swap question, it really devolves down to the resource
accounting issue, which you get into whether you have swap or not: how well
does NetBSD deal when there is no more RAM (or RAM+swap)?

I know that the MACH VM had this notion of "lazy allocation" which allowed
for large, sparse address spaces, but lost terribly if a resource crunch
hit. I also know that we've been tightening up on the resource accounting
with UVM, but it's not clear to me what we do for the "sorry, we're all
out" case right now.

I'm all in favor of the suggestion that was made the last time this came
up: a VM with two behavior modes: strict accounting, and lazy accounting,
where the strict model doesn't allow anyone to allocate more RAM than you
have, and the lazy model allows you to ask for whatever you want, just so
long as you don't use it all. This sort of thing probably has to be a
system-wide policy decision, though there was a suggestion that it could be
per-process, provided that a process which requested lazy allocation would
be the first to die in a crunch.

I'm not thinking of running long-term this way (I got a warning in E-mail
that CD-ROM drives don't like to be run 24x7; they die), but it would be
good to have a robust install/rescue/recovery CD-ROM environment that could
run a full NetBSD system off a CD-ROM. Heck, if we do decent caching, we
shouldn't even need to hit the CD-ROM drive all that hard, possibly even
spin it down after some idle period. Mebbe turn off demand-paging of
binaries off the disk ... ?

	Erik <fair@clock.org>