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