disk performance
Mr. Gircys
fiasco at infoserv.com
Sat Aug 18 09:24:54 AEST 1990
I recently had to remake my .../spool/news file system because it ran out
of inodes. I remade the file system using default values (9 400) for
the mkfs gap and blks/cyl paramaters. Great, so now I have enough inodes
but I notice that rnews seems to take about twice as long to run. A few
simple tests verified that my new file system was 35% slower than those
created during system installation. (As an aside, let me bash Esix tech
support for once again batting zero - I called and asked them very simply,
what values for gap & blks/cyl does your install use when it runs the
mkfs command so that at the least, I end up with performance as good as that
provided during install? Their answer was use the mkfs defaults (that is,
gap & blks/cyl are not specified), hence that's the way I did it.)
Obviously the system install used more appropriate mkfs values than default,
and a 35% hit in performance was unacceptable; so I experimented and
here are the surprising results (normalized to performance of file systems
created during install):
install mkfs default mkfs empirical mkfs
file copy 1 1.35 0.7
file read 1 1.25 0.5
What's surprising is that without to much effort, I found empirical
mkfs gap & blks/cyl values that improved file reads by 50% over the
file systems as made during the install process (are you listening
Esix?). File copy was improved by 30%. In a way I wish this hadn't
work out like this since now I'll have to remake all my file systems
since the performance improvements are worth it.
Moral of the story: even you might want to set aside a file system
for a little experimentation and see if you're getting the performance
you paid for.
Story particulars: ESIX 5.3.2, SCSI Adaptec 1542 cont, 150 meg disk.
mkfs gap=16 blks/cyl=1024.
P.S. The ESIX OS is great; never had any problems with it. However,
their tech support leaves much to be desired.
P.S.S. Please followup if you know mkfs better than the empirical
level; would be nice to know what I really did.
More information about the Comp.unix.i386
mailing list