From owner-freebsd-hackers  Tue Feb 11 20:39:42 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id UAA24293
          for hackers-outgoing; Tue, 11 Feb 1997 20:39:42 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA24269
          for <freebsd-hackers@freebsd.org>; Tue, 11 Feb 1997 20:39:27 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id PAA30454; Wed, 12 Feb 1997 15:34:42 +1100
Date: Wed, 12 Feb 1997 15:34:42 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199702120434.PAA30454@godzilla.zeta.org.au>
To: freebsd-hackers@freebsd.org, Shimon@i-Connect.Net
Subject: Re: Raw I/O Question
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>For example, we did READ and WRITE to random records in a block device.

It's usually a mistake to use the block device .  It is not raw.  It has
a braindamaged default block size (BLKDEV_IOSIZE = 2048).  Write errors
on it can't be reported to the application.  Benchmarks on it aren't
interesting.

>We see a depression in READ and WRITE performance, until block size
>reaches 2K. At this point performance picks up and levels off until
>block size reaches 8KB.  At this point it starts gradual, linear
>decline.

2K is magic (see above).  I would expect read and write performance to
increase with the size below 2K too.  I would expect performance to be
abysmal for all sizes unless the controller and drive very low command
overhead and/or very effective caching.

Bruce