I've got a single 40 GB IDE disk so stripping isn't an option :(

Swap space is about 256MB, period.  I can't get a crash dump with this 
configuration; however, I think I may be able to pass a smaller memory size 
into the kernel at boot time to  use 256MB of physical memory and thus be 
able to generate a crash dump if needed.

Most of the disk (about 30GB) is devoted to my real "pay-the-bills" job and 
requires WindowsME.  Such is life....

At 01:52 PM 5/7/2001 -0400, you wrote:
>[ On Monday, May 7, 2001 at 11:16:26 (-0400), Steven Grunza wrote: ]
> > Subject: mount_mfs questions
> >
> >    I'm running NetBSD-1.5 on a P4 with 1GB of memory.  I keep getting 
> "file
> > system full" messages when /tmp overflows rebuilding the locate
> > database.  Since I typically only use 100 to 200 MB of physical memory
> > while running, I'm considering creating a 256MB MFS drive mounted as
> > /tmp.
>
>Personally I'd go for at least 500MB MFS /tmp on a machine like that --
>and make sure that I have at least 1GB of swap too (hopefully striped
>across 4 or more spindles).
>
>Though capturing a crash dump on such a large machine might be more time
>consuming than it's worth.  Crash dumps and savecore runs on even my 192MB
>machine are slower than I'm usually willing to tolerate....
>
>On this 192MB machine I have a 256MB MFS /tmp and I can fill it at least
>half full (eg. when unpacking a tar file) without causing too much
>thrashing.  In fact I've found that using it for unpacking tar files and
>then doing things like "cvs import" across the result is more efficient
>than even using separate spindles for the job, even when there's lots of
>other stuff running on the machine.  Of course I have four swap
>partitions of 500MB each too, each on UltraFAST/WIDE drives.  I learned
>a long long time ago, back when I was driving 1-4 MIPS machines with 4MB
>or less of RAM way beyond their capabilities that there's nothing better
>for improving things than having lots of fast spindles to swap to (other
>than of course having far more RAM than you can ever use! ;-).
>
>One you move to 1.6 (or -current) the unified buffer cache may change
>your memory utilisation and depending on your job mix may require you to
>readjust some sizes.  I'm still quite happy with my over-sized MFS
>because I don't use /tmp very often, at least not for anything of any
>size, but when I do it is really for something that's of a very
>temporary nature that needs to run quite fast such as the the "cvs
>import" jobs I mentioned.  I do find when watching with systat that UBC
>alone causes far more paging activity overall than the MFS did, but with
>fast swap devices it's not really painful at all.
>
>--
>                                                         Greg A. Woods
>
>+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
>Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>



----------------------------------------------------------------------
"Luke, you're going to find that many | Steven Grunza
of the truths we cling to depend      | voice:  (856) 787 - 2759
greatly on our own point of view."    | fax:    (856) 866 - 2033
  - Obi Wan Kenobi, Return of the Jedi | mailto:steven_grunza@ieee.org
----------------------------------------------------------------------