gerry@swift.cs.tcd.ie (06/07/91)
I would like to increase the /, /usr & /var partitions on our V4.0 system. The obvious way to do this, it seems to me, is to boot from the standalone tape and dump the file systems out, change the partitions sizes and then restore. Are there any possible problems that I am overlooking? Gerry O'Brien, Dept. of Computer Science, Trinity College Dublin, Ireland gerry@cs.tcd.ie
grr@cbmvax.commodore.com (George Robbins) (06/08/91)
In article <1991Jun7.122711.7953@swift.cs.tcd.ie> gerry@swift.cs.tcd.ie writes: > I would like to increase the /, /usr & /var partitions on our V4.0 system. > The obvious way to do this, it seems to me, is to boot from the standalone tape > and dump the file systems out, change the partitions sizes and then restore. Are > there any possible problems that I am overlooking? 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. To move/expand /usr, you will have to do a dump/restore to external media or reinstall the system using the advanced installation path. /var is usually small enough to use disk as an intermediate media but tape is safer. The only one you really need to do by booting the installation media is root. If you have a second drive, it's easier to copy the root parition to the there and diddle the drive nubmers, working the standalong environment involves primitive operations like mknod and mkfs *after* you've probably blown away your operating system. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
ggm@brolga.cc.uq.oz.au (George Michaelson) (06/09/91)
grr@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. 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. 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. -George -- George Michaelson G.Michaelson@cc.uq.oz.au The Prentice Centre | There's no market for University of Queensland | hippos in Philadelphia Phone: +61 7 365 4079 QLD Australia 4072 | -Bertold Brecht
grr@cbmvax.commodore.com (George Robbins) (06/09/91)
In article <1991Jun9.025830.3313@brolga.cc.uq.oz.au> ggm@brolga.cc.uq.oz.au (George Michaelson) writes: > grr@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@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)