From owner-freebsd-scsi  Wed May 28 17:30:18 1997
Return-Path: <owner-freebsd-scsi>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id RAA13527
          for freebsd-scsi-outgoing; Wed, 28 May 1997 17:30:18 -0700 (PDT)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA13521
          for <scsi@FreeBSD.ORG>; Wed, 28 May 1997 17:30:14 -0700 (PDT)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5])
          by mail.cdsnet.net (8.8.5/8.7.3) with SMTP id RAA14209;
          Wed, 28 May 1997 17:30:05 -0700 (PDT)
Date: Wed, 28 May 1997 17:30:03 -0700 (PDT)
From: Jaye Mathisen  <mrcpu@cdsnet.net>
To: "Justin T. Gibbs" <gibbs@plutotech.com>
cc: scsi@FreeBSD.ORG
Subject: Re: More ahc0 driver problems. 
In-Reply-To: <199705282240.QAA02847@pluto.plutotech.com>
Message-ID: <Pine.NEB.3.95.970528172553.15391Y-100000@mail.cdsnet.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


Hmmmm, I'm not sure I understand this.

Under iostat, the drives maintain a constant 6000-7000 blocks writing,
and there are no seizures/freezeups of any kind, just the constant stream
of "errors".

Also, it's on a ccd, which should be splitting up the I/O's over both
drives.

Will write-caching help or hinder this problem?

And lastly, would it be possible (since it's not really an error then),
the big blast of messages suppressed, or only printed via  a config
variable?

On Wed, 28 May 1997, Justin T. Gibbs wrote:

> >Under bonnie to a ccd of sd2, sd3 (WD 4.1GB Enterprise drives):
> 
> ...
> 
> >Reams and reams of them.  WHen it gets to the rewriting phase, it quiets
> >down.
> 
> This problem has been mentioned many times before on this list.  You are
> doing sufficient I/O local to one area of the drives that the drive is
> "starving" transactions that would require a long seek to complete for as
> long as 10 second.  That's the reason the ordered tagged transaction (which
> basically means complete everything else before you run me) clears up the
> condition.  Some changes coming down the line that turn synchronous writes
> into async, ordered writes will help to mitigate this problem as there will
> be an occasional ordered tagged transaction in the stream being sent to the
> driver.  Of course, if you mount your filesystem async, this wouldn't 
> happen.
> 
> The Linux Buslogic driver works around this problem by simply sending an
> ordered tag "every once in a while".  I don't really like that solution
> much.