🚀 go-pugleaf

In article <1992Oct1.020322.1754@cube.handheld.com>
	jmd@cube.handheld.com (Jim De Arras) writes:
>                                   Well, the problem (if it is one) is that
>newfs (and BuildDisk) make a table for the fs that generates a warning that the
>4096 bytes per inode is not possible, and it will use 4490 bytes per inode.
>Not knowing enough about the topic, I just 'feel' that the 4490 bytes per inode
>will be a bad fit on a 1024 bytes per sector HD.

bytes per inode has nothing to do with sector size.  It's a guess
of the average file size on that filesystem.

Each filesystem has space for file data, and space for inodes.
You need one inode for each file.  If you run out of inodes,
you can't create any new files.  If you have more inodes than
you need, you have less space available for file data.  You can
choose where to draw the line, but it's obviously safer to err on
the side of more inodes.

How many inodes do you need?  That depends on how many files you
want to have.  For most people, that's directly related to
filesystem size.  If you have bigger disks, you can have bigger
filesystems, and if you have bigger filesystems, you can store
more files.  Assuming that things scale linearly, the average
file size remains more or less constant.  So rather than
specifying the number of inodes, you're adjusting the inode-to-
data ratio.  If, for example, you're setting up a filesystem to
spool usenet news, you're going to want to tune it for primarily
a lot of small files (RTF silliness notwithstanding).  If you're
going to have a huge swapfile in there, you can reduce the number
of inodes, etc.

Things are complicated somewhat by cylinder group constraints.
In particular, each cylinder group can only hold 2048 inodes.
The warning you saw meant that you didn't have enough cylinder
groups to supply the number of inodes you requested.  By reducing
the cylinders/cylinder group ratio, you got more cylinder groups.
Optimum values are a function of disk geometry, and thus vary
between drive models.

If none of this makes any sense to you, check out chapter 7 of
_The Design and Implementation of the 4.3BSD UNIX Operating
System_ by Leffler, McKusick, Karels, and Quarterman, which has a
reasonably detailed explanation of the Berkeley FFS.

					-=EPS=-