increasing the size of the root partition

[George Robbins]

In article <1991Jun9.025830.3313 at brolga.cc.uq.oz.au> ggm at brolga.cc.uq.oz.au (George Michaelson) writes:
> grr at cbmvax.commodore.com (George Robbins) writes:
> 
> 
> >You should think twice before increasing the root parition size.  Yes, it is
> >tight, but generally you shouldn't be adding anything except symlinks and
> >mount points.  Root should be limited to the kernel and the basics needed for
> >single user mode operation/recovery.
> 
> Except that certain changes to Ultrix like DECnet phase V may blow the
> current / partition size out of that water. You have no safe way of
> doing an UPGRADE with / too small short of smashing it entirely during
> the upgrade or resizing it beforehand.

I suppose this is possible, but more "upgrades" come in the shape of complete
installs than incremental upgrades.  I've found it more important to keep
things in shape for easy rebuilding of the system disk than worrying about
upgrades.

> RISC / seems to be much nicer under 4.2 than 4.[01] -Its around 10Mb
> instead of 13 which is too close to the 15Mb size DEC chose,  if you
> leave /tmp on root that is.

Who would leave /tmp on root?  Better to use a spare a or b partition,
or if you only have a drive or two, make in a link to /usr/tmp == /var/tmp.

Perspectives vary depending on whether you are setting up a single user
one or two drive workstation or a multi-user timesharing system with
some extent of disk farm.

I'm in the latter category and found the best way to avoid pain to is
use partitions to isolate different activities that are capable of
filling up a filesystem so that when it does happen, the extent of
damage is limited.  Also it is vital minimize the admixture of your
local software and what comes with DEC since you have to untangle the
mess everytime you do a new upgrade.

I've also learned that it is important to segregate data with different
backup requirements.  I prefer to do monthly level 0 dumps and daily
incrementals.  To minimize the amount of data on the daily incrementals,
I divide things up into categories: (1) don't need incremental backup,
(2) need incremental backup but trivial volume and (3) user filesystems.
Examples of (1) are /var and /news, (2) /usr, /, archives.

Note that some caution is needed, as an administrator you might think
that /var is volitile and can be restored from an old level zero or
rebuilt, but chances are your users think that their mail boxes (in
/{var,var}/spool/mail) are forever.

On the other hand creating paritions willy-nilly isn't such a great
idea, since they each require backup attention and are always too
small.  Most of my disks are partitioned as "a", "b" and the rest
in one "d" parition.   The a's and b's are my "overhead" they aren't
for user file storage, but are used for back roots, /tmp and so on,
with as many used for swap space as needed.

> Personally I think making root bigger is sensible. It means keeping
> spare kernels around and having non-standard shells like tcsh and bash
> in /bin instead of symblinked into it is viable. 

Keeping an extra kernel is a good idea, but I've always found room for
two.  Blow off genvmunix and just keep /vmunix.old the current kernel.
In case of disaster, keep a duplicate "a" parition and/or know how to
use the standalone system on the distribution tape.  Those extra shells
should be be kept in a .../local/bin with a symlink if you feel compelled
to make them look "natural".

here what I have as a system layout:

/		this is pretty much as the distribution builds it
		there is a /mount directory with a subdirectory for
		each system, so that any filesystems mounted from
		system foo are mounted on /mount/foo/ - creative use
		of symlinks lets this appear uniform across the network.

/backroot	a periodic dd copy  of root on a spare "a" partition

/tmp		isolated (and large) to avoid hassles when /tmp fills up

/usr		virtually read-only and exported to workstations as /usr

/var		variable part of /usr - /usr/spool and so on. note that
		/usr/spool/mail isn't here since you want it somewhere that
		never (sure 8-) fills up and is subject to daily incremental
		backups - I have it symlinked to /local/mail at the moment.

/local		every possible bit of locally modified or created system
		software.  symlinks are used extensivly to organize things
		for instance most entries in {/usr}/local/bin are symlinks
		back to a source|build|bin directory.  also includes things
		like /local/man, /local/etc.

/stuff		all the PD and reference stuff that doesn't need frequent
		backups and can be taken offline if need be. /usr/adm/crash
		goes here, since there is room and (theoretically) nothing
		stops working if some 32M-byte crash dumps fills it up.
		Somehow /usr/tmp is here too, kind of a compromise.

/news		the news spool - if you isolate this, when it gets full, it
		stays full, if you share it you end up with lots of truncated
		articles as free space appears and dissapears.  Put the news
		"library" with it's history and log file elsewhere.

/cats		user filesystems - groups known to consume large amounts of
/unix		diskspace get their own parition so that they are responsible
/softeng	for cleaning up and arbitration when they fill it up, not me!
/pcb

/misc		general user file system - all the diddly types with normal
		personal or e-mail only disk requirements.

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr at cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)