Lesse, / is for booting, /usr is for data and binaries
that don't change, /var is for changable data (dhcp leases,
mail & print spools of all types, locate.db, etc).

/home (or whatever you call it) is for users to read/write their
hearts out.

If TeX needs fonts, that just screams for /usr/share/ or similar,
it's not dynamic, its stuff needed by the app to run, it's not
data.  It has no place in /var/.

My mail machines get a /var/mail/ partition so they don't squish
logs and logs don't affect them.  On high perm machines, /var/mail
(ok, /var/imap/) is a different spindle than /var/log/.

/usr is readonly.  You have to take an extra step to make
changes that should be well thought out an documented.

/ is big enough for a couple kernels and the usual stuff,
but not much more (50-60MB is fine here).  Been mounting
it r/o with an MFS /dev of late - no fsck, less risk of
accidentally changing something on a production machine
that needs to be documented first.  Sure, "mount -uw /"
changes it, but it's makes fewer casual changes.

Quoting Richard Rauch (rkr@olib.org):
> Re. http://mail-index.netbsd.org/netbsd-help/2003/02/06/0026.html
> 
> In addition to the other comments, I would add the following:
> 
> /var is a dumping-ground for *some* (very few) applications that store
> large amounts of user-data.  In particular, TeX dumps its font bitmaps
> there.  At one point, I did a check of my TeX font data in /var,
> and it was over 50MB.  And, of course, /var/mail is where your mailboxes
> go, so if you don't move mail somewhere else (or cause /var/mail to
> be a mount-point or symlink), you can soak up disk space, there.
> 
> Some suggestions have been made to solve this.  I'd add:
> 
>  * Put everything on one big partition.
> 
>  * If TeX is your only problem, you *can* configure it to put
>    its fonts in a non-default directory.
> 
>  * Put /var under /usr and symlink it.  (^&
> 
>  * On a PC where disk space is relatively cheap and vast, I'd make
>    / at least 100MB (unless it's an old PC with a tiny disk and you
>    can't relace the disk drive for some reason).
> 
>  * On the off-chance that you've got a huge mailbox in /var/mail,
>    you might move that.
> 
> For reference, here's my "df -k" output:
> 
> Filesystem  1K-blocks     Used     Avail Capacity  Mounted on
> /dev/wd0a      274967    42953    218265    16%    /
> /dev/wd0f      297447    29058    253516    10%    /var
> /dev/wd0e    36795954  9389811  25566345    26%    /usr
> kernfs              1        1         0   100%    /kern
> 
> ...this is on a 40GB drive.  (Slightly long story, but it's the
> smallest disk I could find to replace a 20GB drive that was
> showing some hardware problems.)
> 
> You'll note that I tried putting /var on its own partition here.
> I didn't know how much space it would need, since I don't know
> when the next application will come along that thinks that
> /var is its massive archival store.  Lots of wasted space, but
> that's okay; the disk will never fill up anyway.
> 
> 
> -- 
>   "I probably don't know what I'm talking about."  --rkr@olib.org