Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!ibmpa!qe2.tcspa.ibm.com!steve
From: steve@qe2.tcspa.ibm.com (Steve DeJarnett)
Newsgroups: comp.sys.pyramid
Subject: Re: Can a filesystem be larger than its base partition?
Message-ID: <3086@ibmpa.UUCP>
Date: 27 Nov 89 23:51:09 GMT
References: <309@trux.UUCP> <308@trux.UUCP> <91317@pyramid.pyramid.com>
Sender: news@ibmpa.UUCP
Lines: 106

In article <309@trux.UUCP>, car@trux.UUCP (Chris Rende) writes:
> In article <91317@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl
S. Gutekunst) writes:
> > In article <308@trux.UUCP> car@trux.UUCP (Chris Rende) writes:
> > >On the Pyramid (BSD), Can a file system cross partition boundaries?
> > 
> > Sure. Using the -s option to newfs. We go both ways -- making the
filesystem
> > either larger or smaller than the standard size.
> > 
> > Be careful of doing this sortof thing on the 00 disk; OSx "knows"
that 00b is
> > for swapping

	Actually, isn't it more like OSx knows that the 'b' partition of the
drive on which
the root filesystem is loaded is a swap partition?? (i.e. if your root
lives on 01a, then
OSx knows/assumes that 01b is a swap partition).

> Are there any other gottcha's that OSx "knows" about?
> Does the ROOT partition have to be 00a?

	At least under 4.4, the root could be any 'a' partition (I know that
for certain 
because I ended up having to try it).  It may allow root to be on a
partition besides 'a',
but I can't say for certain whether that's true.

> What I'm trying to do is increase the size of my ROOT and USR file systems
> in order to make room for TOS 3.3 (OSx 4.4).

	You should be able to fit all of ROOT on an 'a' partition IF you keep the wtmp
logging on another partition or delete the wtmp file fairly regularly
(the system I used 
to run deleted it every week -- this was on a heavily-used 98x).  I
wouldn't advise 
making your ROOT partition non-standard.  In fact, it may not be
possible unless you never
plan to upgrade OS's again.  If you make your ROOT non-standard, then
when you upgrade, 
you would have to first back up EVERYTHING (at least everything on one
of your 'a' 
partitions), then install TOS, then make new partitions that TOS knows
about, copy all 
of the data to the new ROOT partition, then reboot with that info. 
That's a lot of work
for a small gain (in my opinion).  So, you might want to consider having
an 'a' partition
for root (with suitable pruning of log files, etc.).

	As for making /usr larger, I'd say that I don't recommend it, but it's
not as bad
as trying to make ROOT larger (my last system had a non-standard /usr). 
If you do, place
it on a different drive from root, then create it as an 'h' partition. 
Make it large
enough to hold log files, etc. that tend to grow.  What you will end up
doing when you do
a new OS install is loading root onto it's partition, stopping the
install.  Editing the
fstab on disk to ignore /usr for the time being, booting off of the
disk, recreating your
'h' partition in conf.c, adding /usr back into /etc/fstab, build a new
kernel, then reboot.
After this you should be able to get to your old /usr, at which time you
can run the
installusr (or whatever it was called) portion of the install.  Still a
lot of work, but
doable.

> In order to make more room for my ROOT partition I can add 00b's blocks
> into 00a, giving a 50Mb ROOT partition (I'd use 00a instead of 00j because
> 00a seems to have special meaning as a ROOT partition). But, from the info
> above, OSx would trash my ROOT partition by writing swap/paging stuff into
> it via 00b.

	Yes, it will.  I ended up losing quite a few files when OSx used a 'b'
partition
on the drive I was booting off of to swap.  Unfortunately, at that time,
the 'b' partition
was part of another partition that held user files.  (thank goodness I
had fresh backups!)

> It looks like I have these choices for increasing the size of my file
systems:
> - Use symbolic links for dir's and files which grow so that the disk space
>   is drawn from another file system.

	This is what we did.  All log files and other rapidly changing, dynamic
areas of
the filesystem resided on larger disks via symbolic links.

> Christopher A. Rende

	That's how we handled it.  It may not be the cleanest way ever
invented, but it
does do the trick, and it's not too difficult to deal with.

	IBM doesn't (to the best of my knowledge) own any Pyramids.  All of this was 
derived from past experiences, etc.

Steve DeJarnett			IBM Internal: steve@ibmpa.tcspa.ibm.com
IBM AWD Palo Alto		UUCP:	  ibmsupt!steve@uunet.uu.net
(415) 855-3510			VNET:	  steve at paloalto
These opinions are my own.  I doubt IBM wants them.......