Ross Harvey said:
> [ various questions are raised about the value of diskless/NFS swap ]
> 
> Disks _are_ cheap, but I can think of lots of reasons not to have them,
> but to still have swap configured.
> 
> What about 100 X-terminal-like workstations on a floor?
> 
> What about 100 processors in a parallel array? (Or even just 10 or 20
> processors?)
> 
> What about 100 browser clients in information kiosks?
> 
> What about 1,000 ticket (POS) stations?
> 
> In these cases, you definitely do NOT want the heat, packaging,
> and, most seriously, the reliability problems of a bunch of
> distributed drives, especially since it's rare that one would
> actually swap.
> 
I agree with that, but I have also seen OSes that cannot handle diskless
operation very well.  If some asks me an X1 or even X10 question, then
a $170 disk drive might be the answer.  In fact, just using the disk
drive as a local cache (without any need for the disk needing to remain
intact) might be a better answer.  Note my signature below, I work for
a company that uses OSes in diskless configurations, and the problems
abound.  (And frankly paging performance has been a real problem, and
had to be worked around.)

If someone is running out of swap (due to inadequate amount of local
disk), instead of needing to run without local swap, then not allocating
enough swap is an inadequate planning issue.  Reserving swap space up
front like SVR4 doesn't help the issue.  Better management of the VM internal
data structures does help the issue.  On FreeBSD, we have made some headway
into eliminating unnecessary swap space.  However, we haven't optimized the
paging process to run without swap space (but it does have a lame mode
that I haven't implemented properly yet), and we also haven't optimized the
paging process to run with minimal swap space.

(I had one customer (a subsidiary of my employer) several years ago that
almost lost $150M of business, and the problem was partially due to lack
of planning of required computer resources.  Inadquate swap space was
a big part of the trouble.)

-- 
John
dyson@freebsd.org
jdyson@nc.com