doubling the number of inodes on a partition

[Chris Torek]

(I have no idea why this is `Distribution: usa', but I left that in.)

In article <VERBER.91Feb21171646 at capemay.mps.ohio-state.edu>
verber at pacific.mps.ohio-state.edu (Mark Verber) writes:
>yes, newfs on SunOS 4.0.3 is busted.

It is not entirely broken; it is merely uninformative.  Newer `newfs'es
will warn you when they must adjust some of your parameters (even if
defaulted) in order to make the file system `fit'.

>Under anything later than SunOS 4.0.3 (eg 4.1, 4.1.1) newfs does work,
>and all you have to do is specify your preferred bytes/inodes with the
>-i flag.

This means they have picked up the 4.3-tahoe `fat fast file system'
changes.  (It only took how many years? :-) )

>The problem is that you can't tell mkfs directly how many inodes to
>create.  It figures the number for itself.  There are about 5 numbers
>that interact.  Unfortunately, several of them have maximum or minimum
>values, so you don't even get to specify them.  Altogether, it looks
>like mkfs was designed to make it as hard as possible to increase the
>number of inodes.

No, but mkfs was not designed to be easy to use; that is what `newfs'
is for.  Note that newfs has options to control all the arguments to
mkfs.  (Note also that mkfs is *gone* in 4.3-tahoe, having been merged
right into newfs.)

>In theory, you should be able to specify more than the usual number of
>inodes per cylinder group.

Newfs's `inodes per cg' defaults to the number that gives you the
default 2048 bytes per inode, but on modern large disks this comes out
to well over 2048 inodes per cg (since these disks have more than 4 MB
per cg) given the default cylinger group size of 16 cylinders.  In this
particular example we have 67 sectors/track, 15 tracks/cylinder, and 16
cylinders, or 16080 sectors per cg, or 8232960 bytes per cg.  To give
each 2048 bytes one inode we would need 4020 inodes, almost twice as
many as the hard limit.

>Since you can't increase the number of inodes / cylinder group, you
>have to increase the number of cylinder groups.

Or, equivalently, decrease cylinders per cg (so that bytes per cg goes
down).

>So you have to decrease the number of cylinders per cylinder group.
>This is an argument to mkfs,

(and to newfs: -c).

>so in some cases you can just specify it as 4 or 8.  I've actually gotten
>this to work sometimes.  Unfortunately, sometimes mkfs won't let you
>specify anything less than 16.

Right.  This has to do with the way the rotational layout tables are
built.

>Now things get hairy.  The way mkfs computes the minimum number of
>cylinders per group is sort of odd.  It gets initialized to 16 (at
>least for the disks I've seen).

This 16 comes from (8192 bytes per block) / (512 bytes per sector) =
16 blocks per sector.

>Then a loop is done which divides both cylinders per group and
>sectors per cylinder by 2, until sectors per cylinder is odd.

This is because the rotational tables `cycle' (repeat) for each time
the sectors-per-cylinder is divisible by two.  If spc is 48, for
instance, the rotational tables for a complete cylinder group consist
of one `base' table with 3 slots, repeated 16 times (3 * 16 = 48).  If
spc is 30, the table is made of two identical `base tables' with 15
slots each.  The cylinder group must hold a complete base table.

>If the number of sectors per cylinder starts out odd, of course this
>loop stops immediately, and you get 16 cylinders per group.

More precisely, you get (sectors per block) `cylinders per cycle'.
This cyl/cycle count is used to round up another number (`mincpg count')
which is always 1 or 2 for large disks: it is the number of cylinders
needed to hold the `overhead' data for each cylinder group.  Rounding
1 or 2 up to the nearest multiple of 16 always gives you 16.

>I managed to fix things up by telling mkfs not to use all the sectors
>on a track.  In case this isn't obvious, what I'm doing is telling mkfs
>to ignore some of my disk space.

... which in turn makes the rotational layout wrong, but makes the
tables smaller.

Another option is to reduce the file system block size, but this can
goof up paging.

>When you play this game, you'll also have to reduce the number of
>sectors in the partition.

Better yet, since you are going to lie about the geometry of the disk
anyway, you might as well compute a new geometry that holds almost as
much space.

>  /dev/rxd0e:     175874 sectors in 175 cylinders of 15 tracks, 67 sectors

(175*15*67 = 175875, but we will use 175874....)  Maintaining 15 tracks
per cylinder, but going to 66 sectors per track, compute the new number
of cylinders as:

	175874 / (15 * 66)

which gives 177, or (177 * 15 * 66) = 175230 sectors.  175874 - 175230 =
644 sectors `lost', or 322 kbytes.

If you really need more inodes, claim you have 64 sectors per track, and:

	175874 / (15 * 64) = 183 `new' cylinders

which means you are going to use 183 * 15 * 64 = 175680 = 194 `lost'
sectors, or a bit under 97 kbytes.

Note that while you `lose' less space with the 64-sectors-per-track
pseudo-geometry, the 66-sectors-per-track geometry is closer to reality
and may well give noticeably better performance.  (Then again, it may
not.)

>There's got to be a better way.

Yes: put in the new file system code. :-)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov