4.0.3 install problems

[Nick Copeland]

The following are the summerised replies from information received about
SunOS small file systems. The original problem was that a file system for
news data base was so full of small files that it soon ran out of inodes.
The problem is known at sun, bug id 1008866, and is described with a`
workaround under the heading "Large Disk Filesystems".

Thanks to everybody who help out. One or two of my mailed replies failed.

X-From: gnb at melba.bby.oz.au (Gregory N. Bond)

We had the same problems.  You can't change inodes/cylgrp or
cylinders/group (due to the way internal kernel data structures are
arranged).  What you have to do is lie to mkfs about the geometry of that
disk partition, so that it has twice the number of cylinders with 1/2 the
number or tracks or blocks ber cylinder.  Something like

        mkfs /dev/rxd0e 297000 33 15

will work fine, at some (slight) cost in space and performance.  But it
will double the number of inodes.  We were running here with something
similar for months (but /var/spool/news is now a scsi disk).

X-From: Charles Anderson <cander at unisoft.com>

The way to fix this is to change the cylinders per group from 16 to 8.
This will double the number of cylinder groups, which will double the
number of inodes.

X-From: guy at auspex.com (Guy Harris)

Yes, I think this is a deficiency of the 4.2BSD/4.3BSD file system, fixed
in 4.3-tahoe; SunOS 4.1 will have the 4.3-tahoe file system (basically the
same file system, just with certain restrictions removed).

>I used a block size of 4K once ... but ... the system panicked:
>
>       Jan 22 14:16:15 carol vmunix: panic: segmap_unlock
>
>Why is this? Is this a SUN kernel bug?

Yes.  I think it's written up in the READ THIS FIRST or the READ ME FIRST
or the release notes; SunOS 4.0.x can't cope with file systems with a
block size smaller than the system page size.  This might be fixed in 4.1.

X-From: ccsam at bullwinkle.ucdavis.edu (Sam McCall)

i believe it's a known sun os bug; 4k/1k filesystems simply aren't
supported.  you might try telling mkfs you have 5 heads on the disk
instead of 15; when i did that with my fuji 2372's i got lots more inodes
for a pretty minimal amount of disk space lost.

        mkfs /dev/rxd0e 301500 67 5 8192 1024 16 10 60 2048 t 0 -1

mkfs will decide you have 3x as many cylinders as you really have, and
you'll likely get about that many more inodes (all that depends on the
size of your partition, etc.)  i've been running a system with a bigger
fuji with this sort of kludge and i've not lost performance or stability.

X-From: dougf%mda at nikhefh.nikhef.nl (Douglas Floer)

We had the same problem here.  What I had to finally do was fool the disk
into thinking there are more cylinder groups in the partition and
therefore more inodes.  The fix is actually documented in Sun's STB's
(Software Technical Bulletin) but you have to have PAL support to get
these.  Ask you local Sun office for the August 89 STB and have a look on
page 1019.  Here is some email I got from our Sun support contact on the
problem:

| File systems on large disks do not get an adequate number of
| inodes percylinder group.  Mkfs will not allow creation of more
| than 2048 i/g nor will it allow reduction of the c/g.
| Work around:
|   See the evaluation below. If the user can afford to loose a few
|   tracks/sectors, he should remake the filesystem with the third
|   scheme discussed above by reducing the number of cylinders/group.
|   But now he should make sure that #sector * #tracks should be an
|   even number.
| Evaluation:
|   The number of cylinders per group depend indirectly upon
|   fs_cpc (cylinders per cycle in position table) and cpg has
|   to be a multiple of cpc. cpc = 16 >> x, where x is the largest
|   integer such that "track * sector = N * (2**x)", where N is an
|   integer. In this case "track*sector" is an odd number, and hence
|   x=0, and hence cpc=16. UFS depends upon the cpc to find out the
|   rotational position of the sector. This would be a difficult bug
|   to fix. See above workaround. With that one can reduce the number
|   of cylinders per group.
|   The max number of inodes per cylinder group is MAXIPG which is 2048
|   now. Changing that parameter will require recompiling both the
|   utilities like mkfs.c and the kernel. Besides, it also creates
|   backward compatibility problem.
|   So the way to get around it seems to be shrinking the size of a cylinder
|   group so that the effective inode/data ratio becomes higher (see above
|   comments). But for some disk geometry, that is also difficult to do.
|   The problem is that mkfs requires fs_cpg to be a multiple of fs_cpc,
|   which means that a cylinder group size has to be a multiple of file
|   system block size (8K).
|   After examining both the mkfs and the kernel file system code
|   thoroughly, I found that none of the ufs algorithms and data structures
|   depend on that to be true. Even the rotational table stuff will work
|   on file systems where the cylinder group size is not a multiple of 8K.
|   There are only two places in the kernel (ufs_alloc.c) where the
|   calculation relies on this. After reordering the calculation slightly,
|   it seems to work fine.
|   The resolution now is to simply change the format for NEC D2363 w/
|   XD7053 controller from
|    disk_type = "NEC D2363" \
|        : ctlr = XD7053 \
|        : ncyl = 964 : acyl = 2 : pcyl = 1024 : nhead = 27 : nsect = 67\
|        : rpm = 3600 : bpt = 40960 : bps = 600
|    to
|    disk_type = "NEC D2363" \
|        : ctlr = XD7053 \
|        : ncyl = 1009 : acyl = 2 : pcyl = 1024 : nhead = 27 : nsect = 64 \
|        : rpm = 3600 : bpt = 40960 : bps = 600
| The difference is that nsect is shrunk from 67 to 64, and ncyl is increased.
| With a nice number like 64, the user can choose any cpg and the cylinder
| group size will always be a multiple of 8K.