On Fri, 14 May 1999, Mike Cheponis wrote:

: I've been bugged by this limit preventing me from running huge userland
: programs (datasets as big as disk) for 20 years, since I was kernel hacking
: on VAX-11/780s at CMU (surprise, collecting big datasets in the kernel).

Which is, of course, the reason you keep stating for such swap
implementation.  Frankly, "swap on free fs space" has been done, and has 
sufficiently demonstrated its shortcomings in such operating systems as 
... Windows.

`Using large data sets' is not a very compelling argument; Fred Fish's
`mmalloc' has been around for several years, and will do precisely what you
want:  it implements a growable swap area for large data processing.  And in
fact, if you start up mmalloc and immediately unlink() the file while it is
still being used (this trick mainly works on ufs-based filesystems ;), you
end up with an invisible file -- i.e. `taking up spare fs space'.

: So, by making a proposal on this list, I hoped that the wise and bright
: people here would shoot holes in my proposal, and I'd learn where I was
: right and where I needed to think more, because as you know, just having
: a simple idea and actually seeing it running in code is often a long
: distance.

Just as a note of information - there may be experienced minds here, but
there are also big egos here.  Use accusations of `stuck in ... obsolete'
very, very carefully around some of these folk.  8-)

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)