On Thursday, Jun 5, 2003, at 11:36 US/Eastern, Greywolf wrote:
> DL> To have separate /var and /usr you need to know what the system=20
> will
> DL> be used for.  This can only be known by the person installing it.
>
> Not really; it's been common accepted practice for years even in the=20=

> face
> of Big-ass Disks.

First off, thanks for going though this part of the install code.  It's=20=

a chore long overdue.

I'm with Graywolf here, on the pro-split-em side.  My reasoning is=20
similar to his:  /usr doesn't get modified often, usually only when new=20=

software is installed.  /var gets modified all the time.  It hold the=20
databases (locate, pkg, mysql), the log files, the mail spool (both in=20=

and out), printer spools... it's one busy little partition.

If there is file system corruption, either from a bug or a power glitch=20=

or whatever, I'd rather only lose the data on /var -- suck though it=20
would!  -- and not also all the installed software on the system.  At=20
least the system would be usable while I try to recover the data.

It tend to build workstations like this:

/  - fairly small, big enough for base system and a few kernels.  Call=20=

it a half gig.  No softdeps as copying a kernel to a disk that's low on=20=

space will sometimes fail with softdeps when new kernel isn't big=20
enough to fit on the disk until the kernel being overwritten is=20
removed.  Included here is a /kernels directory with GENERIC and=20
MYKERNEL (or whatever I call it) and maybe a test kernel or two. =20
/netbsd is a link to one of the /kernels.  / should contain enough to=20
resurrect a dead system from single user mode in a lab that doesn't=20
have all the network mounts available.

/var - about a gig, definitely softdeps.  The pkg database gets=20
freaking huge, and I've had issues with pkg being unable to mark a=20
package as installed because /var was out of space.  Which means the=20
package depending on it never installs.

/usr - big.  Like 10-15G or more, depending on disk size.  Yeah, this=20
assumes a pretty big disk to begin with.  For smaller disks, I'll favor=20=

this and make /home an NFS mount.  Not written to often, so generally=20
not softdep'd after the system has been built and all the software=20
installed.  Sometimes read-only. This is where non-system-critical=20
software lives.  If I used /usr/pkg it would be on the same partition. =20=

I prefer to set LOCALBASE=3D/usr, but that's another thread.  If it=20
happens to be in a shared networked environment, this sometimes becomes=20=

a shared nfs mount, too.

/usr/pkg, /usr/local - I'm not a big fan of these.  On personal=20
workstations (my typical use) installed software is installed software.=20=

  There's no real difference to the user between "locally built" and=20
system default.  But they do have some use in large scale (e.g.=20
enterprise) environments, and so leaving them as options is valid.

/tmp - mfs.   /tmp IMHO is for temp files that can die if the system=20
reboots.  Like build intermediates or X11 lock files or pkg install=20
workspace.  /var/tmp would be for things that we want preserved over a=20=

reboot, like vi recover files.  I really wish pkg_install would stop=20
using /var/tmp by default.

/usr/src - herein you'd find the checked out NetBSD software source,=20
including /usr/src/pkgsrc.  10G min, softdeps, often a shared NFS=20
mount, tho.  I'll leave out the other rant about build scripts using=20
space outside the /usr/src sandbox by default, like /usr/obj.

/home - usually an NFS mount.  If it's a machine that doesn't have one=20=

nearby, as much as is left, or most of the second drive.  If I'm=20
dual-booting with Linux, I'll use the Linux /home with ext2fs.


When it matters, this arrangement makes backups easier.  /var gets=20
backed up daily, /home daily or weekly (depending on the kind of=20
machine), / and /usr rarely, if ever. /usr/src never.  It also means I=20=

can split this over multiple smaller disks if I need to, or migrate to=20=

shared NFS without huge effort.

Depending on the server, I'd agree with GW in making things like=20
/var/mail a separate partition, but that's a system a new user wouldn't=20=

be trying.

> IMHO:
>
> / and /usr should be relatively static; they won't change that much.
> Maybe they could be the same fs, but that still makes me twitch in a=20=

> bad
> way;

Yes, split 'em.  Makes booting single-user faster and easier, if=20
nothing else.

> /usr/local should not live on the same physical partition as /usr, as
> with more and more packages it will take more and more space;

> /var should not be on the root filesystem at all;
>
> (on a slightly different note...) system logs should not be kept on =
the
> same partition as anything user-writable (including mailboxes);

On large servers, yes.  On personal (even shared) workstations, maybe=20
not.

> Perhaps a "reasonable default pre-layout" should be an option for=20
> sysinst,
> i.e.
> 	[ ] Default layout (best for first-time users)
> 	[ ] Advanced layout (asks questions to determine best layout)
> 	[ ] Custom (user provides all information, with defaults =
pre-set)

I'd actually drop default layout and ask questions anyway.  At least a=20=

couple.  What do you want to do with this system. (personal workstation=20=

/ headless server)  What kind of <answer 1>? (graphics=20
workstation/development workstation / internet terminal)  (thin-client=20=

server / mail server / news server / multi-service server [maybe check=20=

boxes for the services]).

The answers to these may also affect what gets installed, especially if=20=

we package much of the base install, like everything under src/gnu for=20=

starters.  (Do we really need to install TWO mail servers by default?)

Maybe these basic questions would come before the partitioning.

> Putting everything in / is a BIG mistake, IMNSHO.  That way lies=20
> madness.
> Witness Linux.

I don't think that's Linux's downfall, but / as one big partition is=20
indeed bad except where drive space is *so* tight that there's no other=20=

reasonable way of doing it.

jf
--=20
John Franklin
franklin@elfie.org
ICBM: 35=B043'56"N 78=B053'27"W