Berkeley file system tuning
Bruce Anderson
banderso at sagpd1.UUCP
Wed Jan 11 16:47:36 AEST 1989
We are in the process of switching over from an HP9000/540 which
uses a "Structured Directory Format" (proprietary HP) file system
where everything (files, inodes and swap space) are dynamically
allocated, to an HP9000/835 which uses a Berkeley file system with
everything statically allocated at system configuration and I am
wondering if anyone has any data on the effects of some of the
possible configuration tradeoffs.
First, I gather that using multiple disk sections is supposed to
increase speed but from a first glance it appears to do this by
giving you 5 or 6 places to run out of disk space rather than just one
and if you have a file system which is just a little bigger than
one of the sections you can waste incredible amounts of space (for
example if you have 31 MB of data you may have to use a 110 MB
section rather than a 30 MB section). My first question is:
how much speed do you gain by breaking everything up into small
chunks on the disk rather than using it as just one (or possibly
two) very large blocks?
My second question is: how much effect does changing the block and
fragment size have? The manual says that if you use an 8K block and
fragment size it speeds up the file system but wastes space. Does
anyone have a quantitative feel of how much the tradeoff is?
When allocating inodes, what kind of ratio of disk space to inodes
do people use? The default on the system is an inode for every 2KB
of disk space in a file system but this seemed like an awfully high
number of inodes. Is it?
This is probably HP specific but if you define multiple swap sections,
does it fill up the first before starting on the secondary ones or
does it use all in a balanced manner? If the first then obviously
the primary swap space should be on the fastest drive but otherwise
it doesn't matter.
Any information would be appreciated. Post or mail as you wish.
Bruce Anderson - Scientific Atlanta, Government Products Division
...!sagpd1!banderso
More information about the Comp.unix.questions
mailing list