In a conversation between Sean Davis ("Sean: ") and David Laight ("Dave: ")
sometime Today...

Dave:	I'm looking at the install scripts, currently they default swap
	to 4 times systems RAM.  This is a historical figure - I think based
	on the fact that big systems are likely to have more RAM.

	The actual figures are that you need enough swap to be able to
	run your workload, and enough RAM to stop it thrashing.

	However these days RAM is cheap, so it isn't unusual for someone
	to install netbsd on a system with over 1Gb of RAM even though
	the system will never have a working set anywhere near that big.
	Adding 4Gb of swap is getting silly for a single user desktop!

	Although disks are also cheap, it is quite possible that netbsd
	is sharing the disk with other OS (especially on i386).

	I was considering changing the default swap size to the larger of:
	- 1/10th the size of the disk/netbsd partition
	- the amount of RAM (so that you can dump to swap)
	- the smaller of 4 * RAM and 128MB

Greywolf (interjecting):  For what it's worth, I seem to remember the
	point of diminishing returns being 768MB, as stated by Solaris
	about five years ago.  Sure, things change.

Sean:	As far as dumping goes, my understanding is that we dump to the end
	of the dumpdev, right? (so if dumping to swap, and we have 32MB of
	ram and 64MB of swap, the dump will be written to the last 32MB)
	correct me if i'm wrong, but if that is the case, then swap should
	(at least on systems with small amounts of ram) be big enough so
	that the system can boot up and not overwrite the dump if it ends
	up swapping during the boot process, because swap is activated
	before savecore is run. Just my two cents.

Greywolf:  Unless and until we can dump across multiple swap partitions,
	one must have a contiguous partition (or a file!) for swap equivalent
	to length(physmem).

Dave:	I was also considering making '/' at least 1/10th of the disk.  That
	will give some space for /var and /tmp - I've had too much trouble
	with vi running out of space in /var/tmp when editing file of only
	a few 10's of MB...

Sean:	I agree with this - our default for '/' seems too small, to me.
	Especially if you let things accumulate in /var.

Greywolf:  Ya know, I realise that partitioning screws with the writeback
	sort algorithm (maybe it needs some rototilling?), but it's been
	really convenient to have / and /var on separate partitions (and
	/usr, usually on a separate spindle from / and /var, but that's
	just me.  I know a few folks who will vehemently disagree, and I
	will respectfully ask them at this point to remain silent).
	Also, isn't /tmp set to be a mfs by default?

Dave:	The 1/10th is a random fraction - but sharing the space out a bit does
	seem sensible to me....

Sean:	Agreed.

Greywolf:  If /var is separate from /, / can probably survive at 64MB rather
	nicely, with /var at 128MB, give or take, depending on logging, mail
	and such.  It just doesn't make sense to have a 1GB root partition,
	and that doesn't even take into account the dolts who allocate an
	entire 120GB disk to the root filesystem.  No, I will not recant
	that statement, unless someone wishes to show that Systems
	Administration is extremely overrated...

				--*greywolf;
--
NetBSD: unshackling hardware designers and users from the bondage of WinTel.
Partitioning doc: http://www.starwolf.com/greywolf/tech/how2part.html