How to increase inode allocation on disk

[Chip Rosenthal]

In article <226 at bradf.UUCP> brad at bradf.UUCP (Bradley W. Fisher) writes:
>This I'm sure works quite dandy under UNIX systems that have separate
>filesystems for "root" (/) and "usr" (/usr/spool/news), but the default
>for SCO Xenix is to install with *one* file system.

It really is a good idea to break out at least news into a seperate file
system.  This is for two reasons:  management of disk space and disk
performance improvement.  Arguably, your news spool area is one of the
most dynamic on the system, and therefore fragments most quickly.  By
moving news off to another filesystem, fragmentation creep in your other
areas should be slowed.

There is also the problem that your news spool is essentially open to the
world.  If somebody wants to create a 10Meg turd and drop it into
news.announce.important, you've got it.  If /usr/spool/news and /tmp
happen to be on the same filesystem, you're in big time trouble if that
was your last 10Meg.

I also like the psychological thing of having fixed boundaries on the
news filesystem -- that's all the space I'll give it, and things are
tweaked to keep it within bounds.  These fixed walls keep the disk used
by news from having an impact on the space allocated for important and
productive things :-)

>I think the only solution 
>will be to mount my root floppy disk, edit the "mkfs" part of the
>installation scripts, and then reinstall using the modified version.
>If anyone has a better idea for SCO, I'm sure John and I are not the
>only ones in this boat and would like to hear any ideas.

Here is my suggestion.  Get pencil and paper and calculator and spreadsheet,
and design yourself a set of filesystems.  For example, I split up my
150Meg disk into four filesystems:  root, local, user, and usenet.  Among
other considerations, backup policy drove my setup, your mileage may
vary.  With the aid of du, figure out how much space to give each of these
filesystems.  Now, do your backups and re-run the SCO installation script,
but create the individual filesystems.

After completing the SCO installation but before restoring from your
backups, run "mkfs" on your USENET filesystem remake it with the number
of inodes you want.  Now do your restore.  By the way, watch out for the
sparse files (most notably the USENET history file) on the restore - real
disk blocks might get eaten to fill the holes on the restore.  You might
need to do a rebuild of your sparse files after the restore.  Fsck will
tell you which inodes are spares (via the "wrong size" error message), and
ncheck will convert the i-numbers to file pathnames.

One poster said he had 25,000 inodes for a 70M news filesytem (that is
357 inodes/Meg), and found that acceptable.  I have 5664 inodes for a 22M
filesystem (257 inodes/Meg), and find that to be just on the hairy edge.  I
took the SCO default, by the way.  Another factor is that I also keep the
news library and sources on this filesystem, and these are less inode-usage
intensive than news articles (English translation:  they are bigger on
the average than news articles).  If I had nothing but news articles on
this filesystem then I'd have been dead long before I ran out of disk
blocks.  I just ran some quick stats on my spool directory (not the entire
filesystem -- just the spool directory), and found the total usage to be
3562 inodes and 11135 1K blocks, which translates to 328 inodes/Meg.

Hmmm...after all this talkin' I suppose I should get down to it and
rebuild my usenet filesystem!
-- 
Chip Rosenthal                            |  Yes, you're a happy man and you're
chip at chinacat.Lonestar.ORG                |  a lucky man, but are you a smart
Unicom Systems Development, 512-482-8260  |  man?  -David Bromberg