From: Niall O Broin (nobroin at domain sced.esoc.esa.de)
Date: Thu 19 Aug 1999 - 14:43:28 IST
Bernard Tyers said :
> BTW, when formating a HD for Linux, what is the gen with INODE density
> having to be under 1096 (i think)?
Inode density is determined by specifying the number of bytes per inode when you
make a filesystem so you effectively specify the inverse of inode density. BPI
(yeah, I know it more commonly meant bits per inch but those days are gone so here
it means bytes per inode, OK ?) defaults to 4096 and can be a minimum of 1024 - it
also to be a power of 2 i.e. 1K, 2K, 4K, 8K, 16K, 32K . . . but not 6K or 24K. BPI
should be as close as possible to your average file size, which is unfortunately
hard to calculate on a new filesystem :-)
I presume there is an upper limit on BPI though I haven't encountered it. I have a
16GB filesystem which is used for storing JPEGs. I created it with 128K BPI and
it's nearly full. I just had a look at it and I'm feeling rather smug as this was
exactly the right choice - 64K would have been sub optimal, and if I'd used 256K
I've have run out of inodes which is nasty and can only be fixed by backing up,
making the filesystem again, and restoring.
I'm a believer in the one big root religion (if it's good enough for Sun to use on
their own systems, it's good enough for me, though curiously Sun's OS installation
routines don't offer it by default) and I just checked the root filesystems on
three Linux boxen, all made with the default values. On every one of them I've got
far too many inodes. You can examine this with dumpe2fs <partition> which give you
lots of information. In the first page, you get a few lines like
Inode count: 514000
Block count: 2048001
Reserved block count: 102412
Free blocks: 822723
Free inodes: 437578
In a statistically significantly full filesystem i.e. one which is full enough
that you can assume the average file size to date won't change drastically over
time, you can calculate
BPI = ((Block count - Free blocks) / (Inode count - Free inodes)) * 1024
(1024 bytes is the block size. You can change this , but it is not a good idea.)
In the example above, I have configured 4096 BPI but my average usage is 16417 BPI
so the optimum configuration for this filesystem is 8192 BPI. 16384 BPI would save
some more disk space but it would risk getting tight as the disk filled up. As
mentioned, I looked at three boxen and I got values of BPI used of 23205, 16417
and 14096 bytes.
From this rather unscientific survey, I conclude that the default value of 4096 is
probably too low for a Linux installation. To this end, I wrote the Perl script
below for you to try on your own filesystems. Save it somewhere as e.g. opt_bpi,
make it executable, and run it (as root) as opt_bpi partition e.g.
opt_bpi hda1
(Being a nice guy, I've saved you the trouble of typing /dev/)
#!/usr/bin/perl
#
open DUMPE2FS, "/sbin/dumpe2fs /dev/$ARGV[0]|";
while (<DUMPE2FS>) {
if (/^Free blocks: +(\d+)/) { $free_blocks = $1 }
if (/^Free inodes: +(\d+)/) { $free_inodes = $1 }
if (/^Block count: +(\d+)/) { $block_count = $1 }
if (/^Inode count: +(\d+)/) { $inode_count = $1 }
if (/^Block size: +(\d+)/) { $block_size = $1 }
}
close DUMPE2FS;
$bpi = (($block_count - $free_blocks) / ($inode_count - $free_inodes) *
$block_size);
$optimum = 1024;
while ($optimum < $bpi) { $optimum *= 2 }
if ($optimum > $bpi) { $optimum /= 2 }
print "For the mix of files on this filesystem, the optimum bytes per inode is
$optimum $pbi\n";
printf("The average number of bytes used per inode on this filesystem is %5.0f\n",
$bpi);
exit(0);
No bitching about lack of error checking - it's a throwaway :-)
Oh - I never mentioned why you'd go to all this trouble. Inodes consume disk
space, and there's no point having more than you need. I'd presume also that the
speed of an e2fsck is related to the number of inodes, and that's already slow
enough on a big partition.
And while I'm rabbiting on, I should mention the -m to mke2fs switch which
reserves a certain amount of free space for the super user (or others). This is so
that the superuser can recover from disk full situations and also because the disk
allocation routines are faster is they've got some free space to work with.
However, the allocation routines don't care where the free space is so allocation
will only slow down as the disk fills if you use -m 0. However, the default value
of 5% effectively wastes 5% of your disk. On big filesystems used as file stores
use -m 0 (I've discussed this with Remy Card, and it's what he does on his big FTP
servers, so if it's good enough for him) and an appropriate value of BPI.
Whew - that was a long one, as the actress said to the bishop. Somebody throw it
through a text to speech thingie and make a LAID presentation out of it :-)
Kindest regards,
Niall O Broin
UNIX Network Administrator nobroin at domain esoc.esa.de
Ground Systems Engineering Department Ph./Fax +49 6151 90 3619/2179
European Space Operations Centre, Darmstadt, Germany
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:04:28 GMT