Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!mcsun!hp4nl!tuegate.tue.nl!svin02!wsinfo11!debra
From: debra@wsinfo11.info.win.tue.nl (Paul De Bra)
Newsgroups: comp.benchmarks
Subject: Re: IOzone V1.02 Sequential file I/O benchmark UNIX,VMS,MS-DOS,OSF/1,Xenix
Keywords: IOzone V1.03 sequential file I/O benchmark
Message-ID: <1846@svin02.info.win.tue.nl>
Date: 27 Mar 91 10:47:19 GMT
References: <4209@ryn.mro4.dec.com>
Sender: news@svin02.info.win.tue.nl
Reply-To: debra@info.win.tue.nl
Organization: Eindhoven University of Technology, The Netherlands
Lines: 21

In article <4209@ryn.mro4.dec.com> norcott@databs.enet.dec.com (Bill Norcott) writes:
>Attached is a benchmark called IOzone which I have written.  It was inspired
>by Alvin Park's IOstone benchmark (which tests random access I/O).  IOzone
>tests sequential file I/O using the C language.  It writes, then reads, a
>sequential file of fixed length records, and measures the read & write
>rates in bytes per second.  The default is to create a 1 megabyte file 
>consisting of 2048, 512-byte records -- however, these parameters can be
>changed from the command line.

Writing 512-byte records is not a good way to measure sequential file I/O
on most systems. To maximize throughput one should use the same block size
as the file system (these days that's 4k or 8k on most systems except some
old system V systems, pre release 4, that use 1k or 2k file systems).

One important remark to make about the results is that if the measured
throughput is in the order of 80kbytes/sec or less it means that the
file-system gapsize (or the disk-interleaving which is worse) is set
too low, meaning you can write only 1 block per disk revolution.

Paul.
(debra@win.tue.nl)