fsfacca@AVELON.LERC.NASA.GOV (Tony Facca) (08/01/90)
I have a complaint to file, a bone to pick, an axe to grind..
I am wondering if anyone has been inconvenienced by the rather puny /
partition of the Iris 3x0VGX systems running 3.3?
Here is a df:
Filesystem Type blocks use avail %use Mounted on
/dev/root efs 30360 25522 4838 84% /
/dev/usr efs 1144503 382654 761849 33% /usr
/debug dbg 196848 10224 186624 5% /debug
Now, I can live with 2 Meg available, but it sure is annoying. So far, I've
had errors trying to gen a new kernel (I saved the old one as unix.save which
did not leave enough room for unix.install), compiling some codes (I had to re-
define the TMPDIR environment variable), and installing local software (we
use the /tmp directory to uncompress and untar). Nothing terrible, just a
bother.
What appears to have happened either in the 3.2 -> 3.3 conversion or the VGX
upgrade which increased the size of /etc/gl is that the number of blocks in
use went from around 17000 to around 25000.
Has anyone dealt with this situation in manner they would be proud to present?
I've heard of linking /usr/tmp to /tmp but we use /usr/tmp for something else.
I may set the TMPDIR variable in /etc/cshrc, but I don't know what other
surprises await. Can I delete a couple of the files in /etc/gl without causing
more problems (specifically, what are initvideo and setmon doing here?) Are
there other places to look for additional disk space? Should I.. repartition?
Note to SGI: Perhaps it's time to increase the size of the root partition
when you format the disk? Please don't get me wrong. I don't mean to sound
ingrateful, I probably wouldn't remember how to partition the disk myself
anymore if I had to. And it's great that the disks come with eoe1 and eoe2
loaded (with the ALL option!), but 4800 blocks won't cut it.
Humbly Submitted for Consideration,
--
-----------------------------------------------------------------------------
Tony Facca | fsfacca@avelon.lerc.nasa.gov | phone: 216-433-8318
-----------------------------------------------------------------------------
You are at Witt's end. Passages lead off in *all* directions.blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") (08/02/90)
We have the same problem with our 4D/210 VGX and have heard the
same complaint from others here at Langley. It would be nice if the
root partition was a little bit larger. We are still trying to figure
out how to work around this. One thing we have done is to set the
TMPDIR in /etc/cshrc, individually set directory=/usr/tmp for vi & ex.
So far so good. I registered this as a complaint on the hotline.
They didn't seem to have any real solution to the problem, other than
repartioning the disk.
You can't link /tmp to /usr/tmp. We were going to do that, but
we found a socket in /tmp that we couldn't remove. Then the hotline
said we didn't want to do the link because of other reasons that they
didn't go into. I ask them to give me a list of things that use /tmp,
so we could redirect them to /usr/tmp, but they couldn't come up with
a list. We haven't done anything to the kernal yet, however, we are
going to need to in the near future and if there isn't enought space
in root to do it, I guess we would need to repartion.
Some times I wonder if these types of things are check before
they ship these things out. You would think that something as obviously
wrong as this would be found real soon. We found it the first day
we started using the machine.
--
Brent L. Bates
NASA-Langley Research Center
M.S. 361
Hampton, Virginia 23665-5225
(804) 864-2854
E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.govdoelz@urz.unibas.ch (08/02/90)
In article <9008011308.AA17269@avelon.lerc.nasa.gov>, fsfacca@AVELON.LERC.NASA.GOV (Tony Facca) writes: > Filesystem Type blocks use avail %use Mounted on > /dev/root efs 30360 25522 4838 84% / > /dev/usr efs 1144503 382654 761849 33% /usr > /debug dbg 196848 10224 186624 5% /debug > This is a partitioning which is generally undesirable. On our SGI as well as on the other mainframes I am responsible for it proved to be reasonable to create a partition /people in order to separate /usr - files which don't need to be backed up from those who do need occasional save sets. Secondly, desipte the fact that there should be no disk quota on /tmp, it is necessary to create a /tmp partition which is , let's say, 100 megs. This /tmp then can easily be maintained but won't overflow the /usr. You could also create more partitions for software, or different working groups. On a bsd machine I need to keep as optimal as possible, I even have a second root partition which is mirrored to the root partition where unix lives on. In case of trouble, I boot from the other root disk. My df (with modified /root) on the SGI looks as follows: Filesystem Type blocks use avail %use Mounted on /dev/root efs 33460 26550 6910 79% / /dev/dsk/ips0d1s6 efs 43200 34494 8706 80% /usr2 /dev/dsk/ips0d1s5 efs 79800 75678 4122 95% /biozen /dev/dsk/ips0d1s3 efs 235600 232857 2743 99% /profi /dev/dsk/ips0d1s2 efs 193800 185380 8420 96% /software /dev/dsk/ips0d1s1 efs 38000 37996 4 100% /profi2 /dev/dsk/ips0d0s5 efs 50470 14730 35740 29% /tmp /dev/dsk/ips0d0s6 efs 305760 248249 57511 81% /usr /debug dbg 255200 8704 246496 3% /debug Concerning the "/ is full" pity: You can easily softlink a reasonably large file to /usr if this one is not needed at boot time before the partitions other than / are mounted (meaning that 'unix' is not a good example). Concerning the repartitioning: If you are daring enough and have reliable backups on hand, you could try to use the standalone fx in order to modify partition sizes and/or create new ones. Take care of the different disk types, because blocks and cylinders are different dependent on the model you are entering in the first questions of fx. There is an article in a recent 'pipeline' issue about using fx. A caveat is to be considered here: Though fx is capable to have up to 9 partitions, SGI is using only 0, 1, 5 and 6 in the /dev/dsk and /dev/rdsk. This means that you need to create new special files (see mknod(1M)) in order to use partition 2 or 3. You shouldn't touch 7, 8, or 9 because these partitions are special. Hope this helps, Reinhard
merritt@iris613.gsfc.nasa.gov (John H Merritt) (08/02/90)
In article <1990Aug2.082157.853@urz.unibas.ch> doelz@urz.unibas.ch writes: [material deleted] > >Concerning the repartitioning: If you are daring enough and have reliable >backups on hand, you could try to use the standalone fx in order to >modify partition sizes and/or create new ones. Take care of the different >disk types, because blocks and cylinders are different dependent on the >model you are entering in the first questions of fx. There is an article Just have a calculator handy :-) >in a recent 'pipeline' issue about using fx. A caveat is to be considered >here: Though fx is capable to have up to 9 partitions, SGI is using ^^ NO. The answer is 16 >only 0, 1, 5 and 6 in the /dev/dsk and /dev/rdsk. This means that you >need to create new special files (see mknod(1M)) in order to use partition >2 or 3. You shouldn't touch 7, 8, or 9 because these partitions are special. Partitions you can use for making more than one filesystem are: 0 through 6, 11 through 16 Partition 7 can be used to partition the entire disk as one large file system. Warning: [from the peripheral guide] Do not use the two partitions (8 or 9), or the largest parition (10) for mounting file systems. 8 and 9 contain header and replacement track information. The largest partition represents the entire disk, including the header. These partitions contain valuable information which you must not overwrite. If you do, you will be unable to access information on your disk. Actually, I've written to some of these sacred partitions and after a couple of days this warning rang true :-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ John H. Merritt # Yesterday I knew nothing, Applied Research Corporation # Today I know that. merritt@iris613.gsfc.nasa.gov #
bam@rudedog.sgi.com (Brian McClendon) (08/03/90)
In article <9008011308.AA17269@avelon.lerc.nasa.gov> fsfacca@AVELON.LERC.NASA.GOV (Tony Facca) writes: > >I have a complaint to file, a bone to pick, an axe to grind.. > >I am wondering if anyone has been inconvenienced by the rather puny / >partition of the Iris 3x0VGX systems running 3.3? > >Here is a df: > Filesystem Type blocks use avail %use Mounted on > /dev/root efs 30360 25522 4838 84% / > /dev/usr efs 1144503 382654 761849 33% /usr > /debug dbg 196848 10224 186624 5% /debug > >Now, I can live with 2 Meg available, but it sure is annoying. So far, I've >had errors trying to gen a new kernel (I saved the old one as unix.save which >did not leave enough room for unix.install), compiling some codes (I had to re- >define the TMPDIR environment variable), and installing local software (we >use the /tmp directory to uncompress and untar). Nothing terrible, just a >bother. > >What appears to have happened either in the 3.2 -> 3.3 conversion or the VGX >upgrade which increased the size of /etc/gl is that the number of blocks in >use went from around 17000 to around 25000. > >Has anyone dealt with this situation in manner they would be proud to present? >I've heard of linking /usr/tmp to /tmp but we use /usr/tmp for something else. >I may set the TMPDIR variable in /etc/cshrc, but I don't know what other >surprises await. Can I delete a couple of the files in /etc/gl without causing >more problems (specifically, what are initvideo and setmon doing here?) Are >there other places to look for additional disk space? Should I.. repartition? > >Note to SGI: Perhaps it's time to increase the size of the root partition >when you format the disk? Please don't get me wrong. I don't mean to sound >ingrateful, I probably wouldn't remember how to partition the disk myself >anymore if I had to. And it's great that the disks come with eoe1 and eoe2 >loaded (with the ALL option!), but 4800 blocks won't cut it. > >Humbly Submitted for Consideration, >Tony Facca | fsfacca@avelon.lerc.nasa.gov | phone: 216-433-8318 OK, after talking to a unix expert (jwag), the word is there should be no reason /tmp couldn't be a symlink to /usr/tmp. The problematic socket that was mentioned could be an X socket that will go away long enough while booted single-user to create the symlink. You mentioned that you used /usr/tmp for something else... would linking /tmp to /usr/slash_tmp be better? Another solution is to login root NOGRAPHICS, cp -r /etc/gl to /usr/etc_gl (or wherever), and symlink it back. This will move back ~8K blocks. (WARNING: You _must_ undo this change before inst-ing a new release of the software to avoid confusing inst about space remaining/usage on the two partitions.) initvideo is used by /etc/gl/grcond, so it shouldn't be removed. setmon(1) is a user command to change the video mode and can be moved anywhere you want as long as you remember where you put it. We were aware of the issue before shipping 3.3. After compacting as much as possible, ~4K blocks was enough for us to work and build our code, so we made the assumption (probaby bad) that it would be enough for everyone. We will work on this for the next release, but it won't be ready for 3.3.1. ---------------------------------------------------------------------------- Brian McClendon bam@rudedog.SGI.COM ...!uunet!sgi!rudedog!bam 415-335-1110 -----------------------------------------------------------------------------
andrew@alice.UUCP (Andrew Hume) (08/04/90)
i make no claim to expert knowledge here but we decided the ordinary partition layout was not useful to us. our current setup (at least the changed and new partitions) are SMD (1.2GB) DISKS ================== each disk includes the following partitions (you refer to partition P on drive D on controller C by /dev/dsk/xylCdDsP): 0: efs 3+26 / 1: raw 29+150 swap 2: efs 179+150 /tmp 3: efs 329+474 /usr 4: efs 803+800 /u0 5: efs 3+800 /u1 (for comparison: 1: raw 28+81 old swap 6: efs 109+1494 old /usr ) we normally run multiple disk systems (4 typically) with drives 0,1 using partitions 0,1,2,3,4 (both bootable) and all the rest using just 4,5 for usr files. we keep /usr clear of anything that sgi (or other vendors) put there. that way, if an engineer swings by, we can power off our main usr drives and feel better.
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") (08/07/90)
The problem (or disadvantage) with making /tmp a partition is that it is wasted space. If you are not compiling or editting something that space is wasted. If you link /tmp to say /usr/tmp you use your disk space more efficiently. -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov