From owner-freebsd-scsi@FreeBSD.ORG Wed Dec 10 08:21:53 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0119D16A4CE; Wed, 10 Dec 2003 08:21:53 -0800 (PST) Received: from ngfl.dialnet.com (ngmail.ngfl.dialnet.com [212.44.44.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01CF243D29; Wed, 10 Dec 2003 08:21:49 -0800 (PST) (envelope-from ict@cardinalnewman.coventry.sch.uk) Received: from ngmfilt.ngfl.dialnet.com [212.44.44.121] by ngfl.dialnet.com with ESMTP (SMTPD32-6.06) id A757706007E; Wed, 10 Dec 2003 16:18:31 +0000 Received: from relay.ngfl.dialnet.com (unverified) by ngmfilt.ngfl.dialnet.com ; Wed, 10 Dec 2003 16:18:26 +0000 Received: from firewall.cardinalnewman.lan (mime1.datastream.com [172.30.0.70]) by mail.burnhamgrammar.bucks.sch.uk with SMTP (MailShield v2.04 - WIN32 Jul 17 2001 17:12:42); Wed, 10 Dec 2003 16:20:04 -0000 Received: from mail.cardinalnewman.lan (mail.cardinalnewman.lan [192.168.0.3]) hBAGLgKp006590; Wed, 10 Dec 2003 16:21:42 GMT (envelope-from ict@cardinalnewman.coventry.sch.uk) Received: from dumpster.cardinalnewman.lan (dumpster.cardinalnewman.lan [192.168.0.9])hBAGLfcr073500; Wed, 10 Dec 2003 16:21:41 GMT (envelope-from ict@cardinalnewman.coventry.sch.uk) From: ict technician Organization: Cardinal Newman School To: Don Lewis , ianjhart@ntlworld.com Date: Wed, 10 Dec 2003 16:21:39 +0000 User-Agent: KMail/1.5.4 References: <200312061929.hB6JTpeF042644@gw.catspoiler.org> In-Reply-To: <200312061929.hB6JTpeF042644@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312101621.40138.ict@cardinalnewman.coventry.sch.uk> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-32.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_KMAIL version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Filter-Version: 1.11a (mail.cardinalnewman.lan) X-SMTP-HELO: firewall.cardinalnewman.lan X-SMTP-MAIL-FROM: ict@cardinalnewman.coventry.sch.uk X-SMTP-RCPT-TO: truckman@freebsd.org X-SMTP-RCPT-TO: ianjhart@ntlworld.com X-SMTP-RCPT-TO: freebsd-scsi@freebsd.org X-SMTP-PEER-INFO: mime1.datastream.com [172.30.0.70] cc: freebsd-scsi@freebsd.org Subject: Re: More Adaptec 29320 + Seagate ST336607LW woes X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2003 16:21:53 -0000 On Saturday 06 December 2003 7:29 pm, Don Lewis wrote: > On 6 Dec, ian j hart wrote: > > On Friday 05 December 2003 8:33 pm, Don Lewis wrote: > >> I've been meaning to suggest that if you haven't done so already, use > >> "camcontrol modepage" to set the WCE bit to 0 which will disable write > >> caching on the drive. In the testing that I've done, I haven't seen any > >> significant performance penalty in doing this if tagged command queuing > >> and softupdates are in use. It is also safer for soft updates because > >> the drive no longer lies about when write data reaches stable storage. I'll add it to my "things to try" list. Don't want to compromise the data I'm collecting tho'. ie it's a new variable to the equasion. A deep tagged commands queue would be a bit like a cache, wouldn't it? I suspect you would see a significant performance decrease if you also reduced the queue depth. What happens to the queue when I press the power switch? > > > > I thought tagged queuing needed WCE. > > Nope. As near as I can tell, the drive always returns the "Done" > response to a write command immediately if WCE is on, and waits until > the data hits the platter if WCE is off. The difference with tagged > queuing is that while the drive will attempt to do the write as soon as > possible, it will accept more than one command at a time and will > attempt to schedule the physical I/O in some sort of optimim order to > maximize throughput. If the OS wants to enforce a particular order, it > can just wait for commands to complete before sending new ones to the > drive, which is pretty much what soft updates does. I think there are > also some other ways for the OS to constrain the physical I/O ordering. Don't know what I was thinking here. ATA?. Doesn't matter anyway. > > One place where folks have noticed a performance difference between WCE > on and WCE off is when using newfs after we got rid of the buffered > block devices and forced newfs to use the raw character device. Newfs > only issues one write() at a time and waits for the status before > issuing another write(). If WCE is on, the writes only have to hit the > drive cache before the drive returns a status that gets returned to > userland, but if WCE is off the data has to hit the platter before the > status is returned, which slows down newfs quite considerably. Tagged > queuing doesn't make any difference in this case because the drive will > only see at most only one command at a time. -- i j hart ICT Technician Cardinal Newman Catholic School & Community College