From owner-freebsd-current Thu Oct 17 12:07:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA22233 for current-outgoing; Thu, 17 Oct 1996 12:07:16 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA22226 for ; Thu, 17 Oct 1996 12:07:14 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA06333; Thu, 17 Oct 1996 12:04:10 -0700 From: Terry Lambert Message-Id: <199610171904.MAA06333@phaeton.artisoft.com> Subject: Re: Iozone: local vs nfs drives To: jehamby@lightside.com (Jake Hamby) Date: Thu, 17 Oct 1996 12:04:10 -0700 (MST) Cc: mrcpu@cdsnet.net, scrappy@ki.net, current@freebsd.org In-Reply-To: from "Jake Hamby" at Oct 17, 96 10:31:31 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > 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? When you do a write not aligned on a block boundry offset into the file, the file is paged in (read), modified, and written out. In other words, expect writes to: 1) cost as much as a read, and then some 2) cost more proportional to the write block size relative to the page size I would personally epxect writes to be slower than reads. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.