flee@shire.cs.psu.edu (Felix Lee) (08/04/89)
Ran out of inodes yesterday on our /usr/spool partition. A painful experience. C News is mostly graceful in the presence of full disks, but does nothing to protect you from running out of inodes. We ran out of inodes because the best we can get from SunOS4.0.3 on these huge NEC disks we have is one inode per 6.25kbytes. If you average less than 6.25kbytes per file you run out of inodes before you run out of disk space. Pretty silly. The reason it's 6.25kbytes per inode is the (historical) maximum inodes per cylinder group is 2048, and cylinder groups are 14mbytes. Cylinder groups are that large because, (a) there are 27 * 67 sectors per cylinder, (b) there are 16 sectors per block, therefore (c) you need 16 cylinders to fit an even number of blocks without wastage. Unworkarounds are (a) decrease block size (SunOS wants at least 8K), (b) increase MAXIPG from 2048 (no kernel source), (c) allow wastage in cylinder groups (ditto). Workarounds? Right now we're expiring news at a (relatively) furious rate. The filesystem is at 65% capacity and using 85% of the inodes. Sigh. -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!flee
henry@utzoo.uucp (Henry Spencer) (08/06/89)
In article <FLEE.89Aug4114513@shire.cs.psu.edu> flee@shire.cs.psu.edu (Felix Lee) writes: >Ran out of inodes yesterday on our /usr/spool partition. A painful >experience. C News is mostly graceful in the presence of full disks, >but does nothing to protect you from running out of inodes. Sigh... yeah. I thought about this a bit, but if you thought C News had to stand on its head to more-or-less-portably figure out how much space was available, well, finding out inodes is worse. And *most* systems run out of space first. One could modify spacefor to check inodes as well, but it's none too quick as it is. -- 1961-1969: 8 years of Apollo. | Henry Spencer at U of Toronto Zoology 1969-1989: 20 years of nothing.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gnb@bby.oz (Gregory N. Bond) (08/07/89)
In article <FLEE.89Aug4114513@shire.cs.psu.edu> flee@shire.cs.psu.edu (Felix Lee) writes:
Ran out of inodes yesterday on our /usr/spool partition. A painful
experience. C News is mostly graceful in the presence of full disks,
but does nothing to protect you from running out of inodes.
We ran out of inodes because the best we can get from SunOS4.0.3 on
these huge NEC disks we have is one inode per 6.25kbytes. If you
average less than 6.25kbytes per file you run out of inodes before you
run out of disk space. Pretty silly.
The reason it's 6.25kbytes per inode is the (historical) maximum
inodes per cylinder group is 2048, and cylinder groups are 14mbytes.
Cylinder groups are that large because, (a) there are 27 * 67 sectors
per cylinder, (b) there are 16 sectors per block, therefore (c) you
need 16 cylinders to fit an even number of blocks without wastage.
Unworkarounds are (a) decrease block size (SunOS wants at least 8K),
(b) increase MAXIPG from 2048 (no kernel source), (c) allow wastage in
cylinder groups (ditto).
Workarounds? Right now we're expiring news at a (relatively) furious
rate. The filesystem is at 65% capacity and using 85% of the inodes.
I hit this problem last week, on SunOs 3.5 and CDC Sabre-V 1.2Gb disk.
Our workaround: Lie to /etc/mkfs about the disk geometry. Everything
still works, but the optimisations in the file system don't optimise
quite as well. No noticable speed difference on this site.
First, do /etc/newfs on the disk, with -v option. This tells you what
the mkfs command is, something like
/etc/mkfs -N /dev/rrf0a 49800 83 15 8192 1024 16 10 60 2048 t 0
^ ^ ^
which is 83 sectors, 15 heads for our disk. If either of these was
even, divide by two, and you automagically get twice the number of cyl
groups and twice the number of inodes with virtually no performance
loss (as the kernel thinks each physical cyl is two logical cyls).
In our case, we lied a little differently and said
/etc/mkfs -N /dev/rrf0a 49200 41 15 8192 1024 16 10 60 2048 t 0
which lost 600 Blocks (300K) but still doubled the inode count. This
is not a perfect 2-1 mapping, so the optimisation in the filesystem
won't be as effective, but its better than expire -e 4! It's been
going a few days, including 3Mb of news in, no problems. It's quite
safe, as the device-driver interface is in abs blockno terms, not
head/cyl/sect; the info is only used by mkfs in determining the layout
of cylinder groups and superblocks on the partition.
Lest you distrust me on this, I got the info from Robert Elz
(kre@munnari.oz.au) who posted this answer in comp.sys.sun a while
ago. He knows. (Check the /etc/passwd file on the 4.3 tape).
Greg.
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnbhedrick@geneva.rutgers.edu (Charles Hedrick) (08/08/89)
In describing how to increase the number of inodes, you have made what I assume is a typo. You point at sectors per track and tracks per cylinder, and say that if either is even, you divide by two. I think you didn't say quite what you meant. In fact what you want is for the product to be even. So in fact you need to fake things if both are odd, which isn't quite what you said. The primary goal of the operation is to increase inodes in the partition by getting more cylinder groups. This means you have to decrease cylinders per cylinder group. There is an argument to mkfs to specify cylinders per cylinder group. However you can't specify anything smaller than 16 unless sectors per cylinder is even. Of course sectors per cylinder is (sectors per track) * (tracks per cylinder, i.e. number of heads). If that number is even, you can use 8 cylinders per cylinder group. If it is a multiple of 4, you can use 4 cylinders per cylinder group. Etc. I agree with you that lying about the geometry is the right way to proceed. Rather than divide by two, I simply decrease the number of sectors per track by one. In your case, sectors per track is 83, and there are 15 heads. 83 * 15 = 1245 sectors per cylinder. This is odd. By reducing sectors per track to 82, you get 1230, which is even. You can now specify 8 cylinders per cylinder group, and get double the number of inodes. If you need even more inodes, you could use 80 sectors per track, which gives 1200 sectors per cylinder. This is a multiple of 16, so you should be able to specify any power of two for cylinders per cylinder group.
todds@faerie_queene.UUCP (Todd Sandor) (08/10/89)
In article <FLEE.89Aug4114513@shire.cs.psu.edu> flee@shire.cs.psu.edu (Felix Lee) writes:
+Ran out of inodes yesterday on our /usr/spool partition. A painful
+experience.
+The reason it's 6.25kbytes per inode is the (historical) maximum
+inodes per cylinder group is 2048, and cylinder groups are 14mbytes.
+Cylinder groups are that large because, (a) there are 27 * 67 sectors
+per cylinder, (b) there are 16 sectors per block, therefore (c) you
+need 16 cylinders to fit an even number of blocks without wastage.
+Unworkarounds are (a) decrease block size (SunOS wants at least 8K),
+(b) increase MAXIPG from 2048 (no kernel source), (c) allow wastage in
+cylinder groups (ditto).
+Workarounds?
We ran into the same problem here, and got a Workaround from
Sun on this, but we were 'lucky' (didn't have do the workaround)
in that we ran into other problems with the same drive and got the disk
replace with Hitachi drive (if wanna call it lucky you need a disk
replaced). Anyway you should be able to get the Workaround Description
from Sun (reference BugTraq 1008866). The workaround would be a royal
*pain*, as what you do is repartition the drive to reduce the
number of sectors per track from 67 to 64, which mean backup/reload,
and if its the drive with the root and usr partitions on it, then your
in for some fun :-)....(Should be possible though by running the server
as a workstation and doing the work, again great fun...).
The disk capacity stays the same (gets extra from the 60 "spare" tracks
on the NEC), but..... I'm just glad I didn't have to do it, good luck bud...
Get the Workaround description from Sun for the details.
--
Todd Sandor Voice: (613) 738-1338 ext 2704 P.O. Box 9707
Cognos Incorporated FAX: (613) 738-0002 3755 Riverside Dr.
uucp: todds@cognos || uunet!mitel!scs!cognos!todds Ottawa, Ontario,Canada K1G 3Z4
Worlds may change, galaxies disintegrate, but a woman always remains a woman. <st>mouse@mcgill-vision.UUCP (der Mouse) (08/15/89)
In article <1989Aug6.074441.15954@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <FLEE.89Aug4114513@shire.cs.psu.edu> flee@shire.cs.psu.edu (Felix Lee) writes: >> C News is mostly graceful in the presence of full disks, but does >> nothing to protect you from running out of inodes. > Sigh... yeah. I thought about this a bit, but if you thought C News > had to stand on its head to more-or-less-portably figure out how much > space was available, well, finding out inodes is worse. Indeed, there may not even *be* inodes...and when there is something like them, there may not be any limit on how many are available. (Assumption: C news will work when its disk areas are NFS-remote.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
henry@utzoo.uucp (Henry Spencer) (08/16/89)
In article <1614@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >(Assumption: C news will work when its disk areas are NFS-remote.) Ought to, although as we all know, NFS stands for "Not (really) a File System", and there are some violations of Unix semantics that might occasionally cause trouble. We think it wiser to use rsh etc. to take the processing to where the files are. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
guy@auspex.auspex.com (Guy Harris) (08/17/89)
>Indeed, there may not even *be* inodes...and when there is something >like them, there may not be any limit on how many are available. Well, the software from which C news gets its idea of "how many free inodes" could conceivably cough up MAXLONG or something like that. >(Assumption: C news will work when its disk areas are NFS-remote.) Unfortunately, in the case of the current NFS protocol, there's no way to find out how many free files there are on a remote file system, even if said file system supports the notion, which is why e.g. a "df" asking for the number of inodes gives you garbage over NFS. The next protocol revision should fix this.