From owner-freebsd-current  Thu Oct 17 10:31:55 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id KAA14760
          for current-outgoing; Thu, 17 Oct 1996 10:31:55 -0700 (PDT)
Received: from covina.lightside.com (covina.lightside.com [207.67.176.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA14755
          for <current@freebsd.org>; Thu, 17 Oct 1996 10:31:52 -0700 (PDT)
Received: from localhost (jehamby@localhost) by covina.lightside.com (8.8.0/8.8.0) with SMTP id KAA00030; Thu, 17 Oct 1996 10:31:33 -0700 (PDT)
Date: Thu, 17 Oct 1996 10:31:31 -0700 (PDT)
From: Jake Hamby <jehamby@lightside.com>
To: Jaye Mathisen <mrcpu@cdsnet.net>
cc: "Marc G. Fournier" <scrappy@ki.net>, current@freebsd.org
Subject: Re: Iozone: local vs nfs drives
In-Reply-To: <Pine.NEB.3.95.961017025714.16113R-100000@mail.cdsnet.net>
Message-ID: <Pine.AUX.3.94.961017102626.28944A-100000@covina.lightside.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Thu, 17 Oct 1996, Jaye Mathisen wrote:
> 
> 
> I would be interested in the answer to this, I see the same behaviour on
> a 2940/Quantum Atlas combo, although the numbers are quite a bit higher.
> :)
> 
> In any case, given specifically the issue of news, where most activity is
> reading, this is disturbing.
> 
>  > vs local drive (1.78M/s and 938k/s):
> > IOZONE performance measurements:
> >         1784080 bytes/second for writing the file
> >         938585 bytes/second for reading the file

I'm not a filesystem expert, but the results sound normal to me.  Writing
is _often_ faster than reading on modern operating systems and hard
drives that I've used.  Both the OS and the hard drive cache the data as
it's being written and are therefore able to stream it out to the disk as
fast as possible.  However, for reads, the program has to request the
data, _then_ the hard drive has to fetch it, _then_ it has to move from
the buffer cache into your program, while your program is waiting, and
can't submit the next request.

So whereas with writes you are pushing the data out to disk and the write
buffering works in your favor, with reads you are pulling data from the
disk and there is extra latency while your program is captive waiting for
the request.  At least that's how I would explain the situation.

Can any FS hackers confirm/reject my hypothesis?

-- Jake