How to properly partition a disk

[ NOTE: It has come to the attention of this author that partitioning can defeat the elevator sort routines used by the disk cache, thus affecting performance. This notwithstanding, partitioning is still considered more practical in some ways. If you're dead-set against partitioning, you are free to stop reading now, and go on your merry way. I don't need to hear your reasoning, because it's all been taken into account already. Have a nice day.

If you've come this far, please continue and examine the rationales set out before you.]

Q: Okay, now I'm sitting at the installer, and it wants to know how I want to lay out the filesystems. NOW what?

by Greywolf Stardate 5225.6

A: How you partition your system is largely a matter of taste; however, it is recommended that you NOT fall into the laziness trap which has sprung up with the advent of Solaris (and HP/UX), which is the tendency to put everything in one big partition. Well, you can, if you really want to, but most often this is done because there is nothing useful in the root filesystem by itself -- /usr/ must be mounted in order to do ANYthing.

Such is not the case with NetBSD. The root system is small, so that it checks quickly if fsck must be run on it, and yet functional enough so that it needs to be the only thing mounted while you fix the other filesystems, should they need it.

Here is a good guideline for laying out the basic filesystems. Your mileage will definitely vary. These also make sense, somewhat, for diskless layout. Specific diskless recommendations will be added at a later date.

Swap is left until the end of the discussion, as it can be a bit tricky as to exactly how you lay it out (unless you only have one disk).

/ (root) - Should be probably at least 24MB. This is big enough for everything needed to come up single-user, including a kernel.

/usr - 168MB, roughly, seems to be enough to handle the entirety of the base system with enough left over to create the catable man pages. In an ideal world, /usr is mountable read-only. If you want to generate cat pages from man pages on the fly, mounting /usr RO is not an option. If you want base X, make it 224MB, just to be safe; that should be plenty. If you want more than base X, consider putting X and/or third party software on separate (and larger) filesystems.

It is of note that the system installer does not deal with more than one physical disk at installation time. Ideally it would be good to split the filesystem layout such that root and /var are on one spindle (disk) while /usr is on another. It works even better if you can split across controllers. However, since we don't accommodate this at install time (yet), we work with what we have.

/var - Consider the following questions:

How much activity logging do you intend to keep around? (add 1M/day, roughly, for default logging)
Do you intend to do process accounting? (add 500KB/day, roughly, for average process accounting)
How much mail are you collecting on this machine? (be prepared for about 2MB/user; if they're lazy and/or dim-witted, prepare for more.)
How much on-disk temp space do you want? (add it; at least 8M is recommended for optimal conditions)
Do you want to be able to capture crash dumps? (add half the size of the GENERIC kernel plus at least half of physical memory -- it does compress, but still...) (as a reference, the author uses about 64MB and typically has a good 8MB (or more) free)

A good baseline is probably about 32MB, adjusted as above.

For the brave: Make /var/run mfs.

/home (or /users, or ...) - Allocate approximately 500MB/user for personal data. Images and mp3s are probably better off in a central repository (where they're not replicated thrice over). Text data tends to be relatively small. Personal programs (binaries) tend to have one of the following attributes:

Small, and therefore won't take much space.
Large and Generally Useful, and therefore probably belongs in /usr/local somewhere.
Useless. A good candidate for deletion.

The largest offenders tend to be saved outbound mails or massive spams which get accidentally saved and never perused. Trust me on this one. :-)

That's it for your base system. Recommendations for other partitions include:

/usr/src - 2GB to build the system, just to be sure. If you want to put pkgsrc here, too, kick it up to at least 4GB. This includes room for some object files during the build. It's rumoured that a full pkgsrc build without deleting object files can take up to 7 or 8GB. Add another GB for each architecture you intend to cross-compile (system sources only; pkgsrc does not cross-compile due to many complex issues).

/usr/X11R6 - 1.5 GB. Just to allow for an influx of 3rd party X stuff.

/usr/local - Average extraneous stuff installed, about 1-2GB seems to be comfortable. If you're planning on building and installing the whole pkgsrc world, more like 4-6GB (and getting larger), if you can spare it.

/usr/pkg - if you must insist on splitting /usr/local into /usr/local and /usr/pkg, set aside probably 3-6 GB for /usr/pkg and 1-2 GB for /usr/local. This may vary per-site, so be prepared to make adjustments for, i.e., the site which doesn't use pkgs at all (and installs from manually downloaded and tweaked sources).

/export - This is the canonical location where diskless clients are kept if you're going to use them. Allocate space accordingly:

you'll need one root per client BUT only insomuch as /dev and /etc and perhaps a kernel are. The standard binaries (/bin, /sbin) are only necessary at one per architecture and can be hard-linked into place (this takes some planning).
you'll need one /usr per architecture.
you'll need one separate /var per client.
you'll need one swap file per client (see below).

If you didn't understand that last one, chances are you won't be needing to set up diskless clients.

If and when you have unclaimed space, file it away as /export/d#, or /space/d#, or /u/d#, or whatever makes sense to you. The d# (i.e. d0, d1, d2) is there to differentiate the various extra space on the off chance you're not going to concatenate all the leftover space into one big ccd partition :-)

SWAP

Here it is. NetBSD doesn't need swap space, strictly speaking, but it's still recommended. Standard swap allocation is 1-2x physical memory. Use 3x if you're running anything of serious consequence.

Many people assume that you need this space in one chunk. If you have only one disk, well, you're right -- you do.

However, a better approach is to split swap across two or more disks if you have the space to spare.

Moreover, if you intend to be able to do post-mortem (kernel crash) debugging, you will need to have one physically contiguous chunk of disk space the size of physical memory to which the machine will dump on a panic. It may be set aside for dump-only space by specifying it as a 'dp' partition in /etc/fstab. You'll learn more about editing /etc/fstab later (hint: the 'man' command is Your Friend).

If you're going to be running HUGE applications -- Databases Of Unusual Size, Mondo Killer Death Apps or doing lots of image editing or the like, it's recommended that you have a MINIMUM of double physical memory, probably more like three times.

PLEASE TAKE NOTE: There seems to be a point of diminishing returns at about a gigabyte. Chances are that if you have a gigabyte of RAM, you're not going to be swapping all that much, so outside of unusual system requirements (see above regarding DOUSs, MKDAs and image editing), it is highly recommended that you top out at a gigabyte of swap (see notes above on doing post-mortem and splitting swap space).

If you decide to do initial swap space, figure out:

if you'll want to dump kernel core to that spot
if you'll be splitting swap
how much physical memory you have.

Historically, if you gave a swap partition as the very first partition on a drive, you could clobber the disklabel, rendering it quite difficult to figure out where your partitions were.

For this reason, swap typically goes on the 'b' partition (or just about anywhere except 'a'). (This may change in a future release, if it hasn't already done so.)

And there you have it. This should be enough to get you going.