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. Message-ID: <Pine.NEB.3.95.970528172553.15391Y-100000@mail.cdsnet.net> In-Reply-To: <199705282240.QAA02847@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.95.970528172553.15391Y-100000>