From owner-freebsd-scsi Sun Sep 17 1:49:43 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id A575937B424 for ; Sun, 17 Sep 2000 01:49:40 -0700 (PDT) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e8H8nCY08064 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sun, 17 Sep 2000 10:49:23 +0200 (MET DST) Received: from cicely5.cicely.de (cicely5.cicely.de [fec0::104:200:92ff:fe9b:20e7]) by mail.cicely.de (8.11.0.Beta1/8.11.0.Beta1) with ESMTP id e8H8nGI92430; Sun, 17 Sep 2000 10:49:17 +0200 (CEST) Received: (from ticso@localhost) by cicely5.cicely.de (8.11.0/8.9.2) id e8H8nEE67761; Sun, 17 Sep 2000 10:49:14 +0200 (CEST) (envelope-from ticso) Date: Sun, 17 Sep 2000 10:49:14 +0200 From: Bernd Walter To: Geoff Buckingham Cc: Greg Lehey , scsi@FreeBSD.ORG Subject: Re: VInum creation problem Message-ID: <20000917104913.A67722@cicely5.cicely.de> References: <20000911190423.A32285@chuggalug.clues.com> <20000912084942.J19431@wantadilla.lemis.com> <20000912100050.A32446@chuggalug.clues.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000912100050.A32446@chuggalug.clues.com>; from geoffb@chuggalug.clues.com on Tue, Sep 12, 2000 at 10:00:50AM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Sep 12, 2000 at 10:00:50AM +0100, Geoff Buckingham wrote: > On Tue, Sep 12, 2000 at 08:49:43AM +0930, Greg Lehey wrote: > > > I seem to have worked around this now, but will try to provide what information > I can. > > > The best I can think of here would be a parse error, but I've seen > > other people go up to 32 drives (after which there *is* a problem). > > I've had up to about 12 devices on my test box, but they weren't all > > SCSI. A couple of questions: > > > > 1. Does the command-line error always start with da10? > > No specific drives gave problems, da1 da2 da3 da4 da6 and da10. > > The drives had been through some testing here and a little investigating > has turned up the following: > > da5-16 had previously been in a vinum volume, then da1-12 > da1-4 had been in a windows box > da0 the system disk has been in the machine for some time. Zero the first Megs of the vinum partitions to get the old vinumconfig out of the way before adding the drives to vinum. I remember that I had the problem if the drive I want to add to vinum had a different name before. What OS version are you running? It happened for me on a production machine too and I wasn't able to reproduce it with a recent version later so I asumed it's already fixed. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 17 10:39:27 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 00C7237B422 for ; Sun, 17 Sep 2000 10:39:25 -0700 (PDT) Received: (from gibbs@localhost) by caspian.plutotech.com (8.9.3/8.9.1) id RAA00821; Sat, 5 Aug 2000 17:53:31 -0600 (MDT) (envelope-from gibbs) Date: Sat, 5 Aug 2000 17:53:31 -0600 (MDT) Message-Id: <200008052353.RAA00821@caspian.plutotech.com> From: "Justin T. Gibbs" To: mjacob@feral.com Cc: scsi@FreeBSD.org Subject: Re: Problems using a QUANTUM DLT 7000 X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > My gut feeling says parity error. > I was tinking two bit error (undetectable with parity), but otherwise agree with your analysis. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 17 10:39:32 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 5AC3537B424 for ; Sun, 17 Sep 2000 10:39:30 -0700 (PDT) Received: (from gibbs@localhost) by caspian.plutotech.com (8.9.3/8.9.1) id BAA14552; Sat, 16 Sep 2000 01:06:10 -0600 (MDT) (envelope-from gibbs) Date: Sat, 16 Sep 2000 01:06:10 -0600 (MDT) Message-Id: <200009160706.BAA14552@caspian.plutotech.com> From: "Justin T. Gibbs" To: Chuck Robey Cc: scsi@FreeBSD.org Subject: Re: Adaptec 21960 X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > Maybe you shouldn't read too much into that one report, Ken. I have a > different set of symptoms. I can talk to the drive (the IBM 18G > Ultra160), my problem is that I can't coax it into booting. Anything > short of booting (disklabelling, newfs'ing, mounting, running as a > secondary drive) works fine. I do happen to run current, tho. Are you able to load the loader? This smells like a BIOS issue. If you can tell me what MB, MB BIOS Rev, and card BIOS rev you have, I can try to find out if there are any known BIOS issues that might explain your symptoms. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 17 10:39:35 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id EF30437B43F for ; Sun, 17 Sep 2000 10:39:32 -0700 (PDT) Received: (from gibbs@localhost) by caspian.plutotech.com (8.9.3/8.9.1) id RAA00812; Sat, 5 Aug 2000 17:48:40 -0600 (MDT) (envelope-from gibbs) Date: Sat, 5 Aug 2000 17:48:40 -0600 (MDT) Message-Id: <200008052348.RAA00812@caspian.plutotech.com> From: "Justin T. Gibbs" To: mjacob@feral.com Cc: scsi@FreeBSD.org Subject: Re: CAM layer X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > Well, the 'needs' was Justin's take on things. I'm not sure I agree. I tend to > see ATA like I implement SAF-TE inside SES- SCSI/CAM is a superset of what ATA > uses, although there are things in ANSI t13 committee that are not well > represented within t10 (SCSI) yet but can be shoehorned in pretty easily. Regardless of how the person integrating ATA/ATAPI into CAM decides to do this, I feel that the CAM layer should be separated out so that additional protocol types can be grafted to the base. This gives the implementer full flexibility to add support for a new stack in whichever manner seems best. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 17 10:39:37 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 78E2D37B50C for ; Sun, 17 Sep 2000 10:39:35 -0700 (PDT) Received: (from gibbs@localhost) by caspian.plutotech.com (8.9.3/8.9.1) id AAA14523; Sat, 16 Sep 2000 00:53:24 -0600 (MDT) (envelope-from gibbs) Date: Sat, 16 Sep 2000 00:53:24 -0600 (MDT) Message-Id: <200009160653.AAA14523@caspian.plutotech.com> From: "Justin T. Gibbs" To: "Kelsey Womack" Cc: scsi@FreeBSD.org Subject: Re: Adaptec 21960 X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <001801c01ee1$6bd8a950$020a0a0a@tjabring> User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <001801c01ee1$6bd8a950$020a0a0a@tjabring> you wrote: > > It's odd, I have a 4.1-stable server, in production, never had a prob... and > we have the 29160. However, our other 2 machines could never get > to -stable, and I have been told -stable fixes that. The company I used to > work for had about 5 servers with 29160's and the infamous Seagate drives > taht supposedly case this prob, and I was told to just disable write-back > caching in the scsi bios. I had it done, didnt work... I just thought I > would share this with you. > > -Kelsey The issue with the Seagate drives was that they would spontaineously drop off the bus. That doesn't sound like what others are reporting, but then again, its not clear exactly what a "freeze" means. Is the system completely unresponsive to anything including an attempt to drop into the debugger? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 17 10:39:46 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 95C3E37B423 for ; Sun, 17 Sep 2000 10:39:43 -0700 (PDT) Received: (from gibbs@localhost) by caspian.plutotech.com (8.9.3/8.9.1) id BAA14539; Sat, 16 Sep 2000 01:00:15 -0600 (MDT) (envelope-from gibbs) Date: Sat, 16 Sep 2000 01:00:15 -0600 (MDT) Message-Id: <200009160700.BAA14539@caspian.plutotech.com> From: "Justin T. Gibbs" To: David Bushong Cc: scsi@FreeBSD.org Subject: Re: Adaptec 21960 X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <20000915004534.A486@bushong.net> User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <20000915004534.A486@bushong.net> you wrote: > It doesn't seem to happen with all 29160's, but it does seem to happen with > all SuperMicro 370DL3 motherboards. I have IBM 36GB 10k drives, so it's not > that they're Seagates... > > --David Bushong Be aware that even IBM has had firmware issues with their 10K U160 product line. One particular bug made a seek miss a catastrophic event. Oh, and whatever sector you were shooting for would be corrupted too. Unfortunately I don't know exactly which models and firmware revisions were affected. Anyway, I did find reference to one situation that could potentially cause corruption of the controller's per-transaction data area when running the 7892/99 on a 66MHz pci bus. The latest version of the driver (referenced in another piece of email) avoids that issue and may fix this problem. If it doesn't, I'll order up a SM 370DL3 (or find one in our test lab) and see if I can determine what is going wrong on that board. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 17 10:55:22 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from picnic.chuckr.org (picnic.chuckr.org [216.254.96.118]) by hub.freebsd.org (Postfix) with ESMTP id 0AF5B37B423; Sun, 17 Sep 2000 10:55:19 -0700 (PDT) Received: from localhost (chuckr@localhost) by picnic.chuckr.org (8.11.0/8.9.3) with ESMTP id e8HHtA059705; Sun, 17 Sep 2000 13:55:11 -0400 (EDT) (envelope-from chuckr@picnic.chuckr.org) Date: Sun, 17 Sep 2000 13:55:10 -0400 (EDT) From: Chuck Robey To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: Adaptec 21960 In-Reply-To: <200009160706.BAA14552@caspian.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 16 Sep 2000, Justin T. Gibbs wrote: > In article you wrote: > > > > Maybe you shouldn't read too much into that one report, Ken. I have a > > different set of symptoms. I can talk to the drive (the IBM 18G > > Ultra160), my problem is that I can't coax it into booting. Anything > > short of booting (disklabelling, newfs'ing, mounting, running as a > > secondary drive) works fine. I do happen to run current, tho. > > Are you able to load the loader? This smells like a BIOS issue. > If you can tell me what MB, MB BIOS Rev, and card BIOS rev you > have, I can try to find out if there are any known BIOS issues > that might explain your symptoms. Nope. I get a plain blank screen, as soon as the BIOS part of booting is done. I have no indication it gets as far as the loader. I could be a *very* early loader problem, a problem installing the loader, or even a hardware problem totally unrelated to FreeBSD (as far as I can so far prove). I'm quite willing to do testing. Nothing on the drive so far that I coudn't recreate. I have two drives, they act exactly alike. They are IBM DDYS-T18350 18.2 gb drives. There were suggestions much earlier on this list that maybe using the IBM-supplied disk utils to zero the disk would help. I've tried them, zeroing first the boot sectors, and then when that didn't work, the entire disk. No change, it still refuses to boot from the disk. The disk continues to work fine in all other respects. I've tried using both disklabel and boot0cfg (separately) to install the boot code, no luck. ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@picnic.chuckr.org| electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 17 11:53:24 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7B7D337B424; Sun, 17 Sep 2000 11:53:22 -0700 (PDT) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id LAA04293; Sun, 17 Sep 2000 11:53:22 -0700 Date: Sun, 17 Sep 2000 11:53:21 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: CAM layer In-Reply-To: <200008052348.RAA00812@caspian.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In article you wrote: > > > > Well, the 'needs' was Justin's take on things. I'm not sure I agree. I tend to > > see ATA like I implement SAF-TE inside SES- SCSI/CAM is a superset of what ATA > > uses, although there are things in ANSI t13 committee that are not well > > represented within t10 (SCSI) yet but can be shoehorned in pretty easily. > > Regardless of how the person integrating ATA/ATAPI into CAM decides > to do this, I feel that the CAM layer should be separated out so that > additional protocol types can be grafted to the base. This gives the > implementer full flexibility to add support for a new stack in whichever > manner seems best. That's the approach that NetBSD and Solaris have (somewhat successfully) taken for their midlayers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 17 12:25:23 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 51B7F37B423; Sun, 17 Sep 2000 12:25:21 -0700 (PDT) Received: from caspian.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id NAA20020; Sun, 17 Sep 2000 13:25:18 -0600 (MDT) (envelope-from gibbs@plutotech.com) Message-Id: <200009171925.NAA20020@pluto.plutotech.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Chuck Robey Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: Adaptec 21960 In-Reply-To: Your message of "Sun, 17 Sep 2000 13:55:10 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Sep 2000 13:26:17 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Are you able to load the loader? This smells like a BIOS issue. >> If you can tell me what MB, MB BIOS Rev, and card BIOS rev you >> have, I can try to find out if there are any known BIOS issues >> that might explain your symptoms. > >Nope. I get a plain blank screen, as soon as the BIOS part of booting is >done. I have no indication it gets as far as the loader. I could be a >*very* early loader problem, a problem installing the loader, or even a >hardware problem totally unrelated to FreeBSD (as far as I can so far >prove). Can you boot other OSes? I still need to know what MB, MB BIOS Rev, and 29160 BIOS rev you are using. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 17 13: 3:50 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 8D9E637B423 for ; Sun, 17 Sep 2000 13:03:48 -0700 (PDT) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA04738; Sun, 17 Sep 2000 13:03:40 -0700 Date: Sun, 17 Sep 2000 13:03:40 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: Wilko Bulte , freebsd-scsi@FreeBSD.ORG Subject: Re: suggestion for camcontrol In-Reply-To: <20000908161550.A21933@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 8 Sep 2000, Kenneth D. Merry wrote: > On Fri, Sep 08, 2000 at 14:54:09 -0700, Matthew Jacob wrote: > > > > The points about cleanliness are worthy- except the deal here is that the > > interfaces have to be clean. The program 'camcontrol devlist' does not. > > Interfaces don't "have" to be clean, and neither does code that accesses > those interfaces. > > Cleanliness is a choice made by the developer, and in this case I'm chosing > the clean path rather than the quick-n-dirty path. > > The information in question is available through 'camcontrol negotiate -v', > (once I commit the patch) so I don't think there's an urgent need for this, > anyway. We've got time to do this the right way instead of throwing > something in there that will likely stay there a long time. I wasn't paying attention - was this integrated? > > > You should be able to do XPT_PATH_INQ for paths 0 through 0xff to get at the > > list of SIMs. > > Actually, you can't do that at the moment. To do a path inquiry, you need > a device to do a path inquiry on. (i.e. path inquiries can only be done > via the pass driver at the moment, they aren't supported through the xpt > driver.) > > Ken > -- > Kenneth Merry > ken@kdm.org > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 17 13: 4:51 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 752AA37B423 for ; Sun, 17 Sep 2000 13:04:50 -0700 (PDT) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA04747; Sun, 17 Sep 2000 13:04:43 -0700 Date: Sun, 17 Sep 2000 13:04:43 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: Wilko Bulte , freebsd-scsi@FreeBSD.ORG Subject: Re: suggestion for camcontrol In-Reply-To: <20000908161550.A21933@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > You should be able to do XPT_PATH_INQ for paths 0 through 0xff to get at the > > list of SIMs. > > Actually, you can't do that at the moment. To do a path inquiry, you need > a device to do a path inquiry on. (i.e. path inquiries can only be done > via the pass driver at the moment, they aren't supported through the xpt > driver.) Any reason we can't do this through the xpt driver? I'll do it if no objection. This would make some code I have for DUh identical in FreeBSD. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 17 13:10:34 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id 19CFD37B422 for ; Sun, 17 Sep 2000 13:10:32 -0700 (PDT) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #2) id 13akli-0002a3-00; Sun, 17 Sep 2000 20:10:31 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.0/8.11.0) id e8HKBih51425; Sun, 17 Sep 2000 22:11:44 +0200 (CEST) (envelope-from wkb) Date: Sun, 17 Sep 2000 22:11:44 +0200 From: Wilko Bulte To: Matthew Jacob Cc: "Kenneth D. Merry" , freebsd-scsi@FreeBSD.ORG Subject: Re: suggestion for camcontrol Message-ID: <20000917221144.A51411@freebie.demon.nl> References: <20000908161550.A21933@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mjacob@feral.com on Sun, Sep 17, 2000 at 01:03:40PM -0700 X-OS: FreeBSD 4.1-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Sep 17, 2000 at 01:03:40PM -0700, Matthew Jacob wrote: > > > On Fri, 8 Sep 2000, Kenneth D. Merry wrote: > > > On Fri, Sep 08, 2000 at 14:54:09 -0700, Matthew Jacob wrote: > > > > > > The points about cleanliness are worthy- except the deal here is that the > > > interfaces have to be clean. The program 'camcontrol devlist' does not. > > > > Interfaces don't "have" to be clean, and neither does code that accesses > > those interfaces. > > > > Cleanliness is a choice made by the developer, and in this case I'm chosing > > the clean path rather than the quick-n-dirty path. > > > > The information in question is available through 'camcontrol negotiate -v', > > (once I commit the patch) so I don't think there's an urgent need for this, > > anyway. We've got time to do this the right way instead of throwing > > something in there that will likely stay there a long time. > > I wasn't paying attention - was this integrated? I think Ken is looking for a clean way to do this and has put it on his whiteboard as a wish. Could be wrong though.. -- Wilko Bulte wilko@freebsd.org Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 17 13:43:18 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 6B10837B424 for ; Sun, 17 Sep 2000 13:43:16 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id OAA20474; Sun, 17 Sep 2000 14:43:10 -0600 (MDT) (envelope-from ken) Date: Sun, 17 Sep 2000 14:43:10 -0600 From: "Kenneth D. Merry" To: Wilko Bulte Cc: Matthew Jacob , freebsd-scsi@FreeBSD.ORG Subject: Re: suggestion for camcontrol Message-ID: <20000917144310.A20409@panzer.kdm.org> References: <20000908161550.A21933@panzer.kdm.org> <20000917221144.A51411@freebie.demon.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000917221144.A51411@freebie.demon.nl>; from wkb@freebie.demon.nl on Sun, Sep 17, 2000 at 10:11:44PM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Sep 17, 2000 at 22:11:44 +0200, Wilko Bulte wrote: > On Sun, Sep 17, 2000 at 01:03:40PM -0700, Matthew Jacob wrote: > > On Fri, 8 Sep 2000, Kenneth D. Merry wrote: > > > > > On Fri, Sep 08, 2000 at 14:54:09 -0700, Matthew Jacob wrote: > > > > > > > > The points about cleanliness are worthy- except the deal here is that the > > > > interfaces have to be clean. The program 'camcontrol devlist' does not. > > > > > > Interfaces don't "have" to be clean, and neither does code that accesses > > > those interfaces. > > > > > > Cleanliness is a choice made by the developer, and in this case I'm chosing > > > the clean path rather than the quick-n-dirty path. > > > > > > The information in question is available through 'camcontrol negotiate -v', > > > (once I commit the patch) so I don't think there's an urgent need for this, > > > anyway. We've got time to do this the right way instead of throwing > > > something in there that will likely stay there a long time. > > > > I wasn't paying attention - was this integrated? > > I think Ken is looking for a clean way to do this and has put it on his > whiteboard as a wish. Could be wrong though.. Well, there are two different issues here. One is getting the initiator ID into 'camcontrol devlist', and that is indeed on my list of things to look at. The other issue is getting the initiator ID into 'camcontrol negotiate -v', and I just checked it in. (Thanks for the reminder!) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 17 13:58:18 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 7DCA637B422 for ; Sun, 17 Sep 2000 13:58:16 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id OAA20626; Sun, 17 Sep 2000 14:58:11 -0600 (MDT) (envelope-from ken) Date: Sun, 17 Sep 2000 14:58:11 -0600 From: "Kenneth D. Merry" To: Matthew Jacob Cc: Wilko Bulte , freebsd-scsi@FreeBSD.ORG Subject: Re: suggestion for camcontrol Message-ID: <20000917145811.A20608@panzer.kdm.org> References: <20000908161550.A21933@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mjacob@feral.com on Sun, Sep 17, 2000 at 01:04:43PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Sep 17, 2000 at 13:04:43 -0700, Matthew Jacob wrote: > > > > > You should be able to do XPT_PATH_INQ for paths 0 through 0xff to get at the > > > list of SIMs. > > > > Actually, you can't do that at the moment. To do a path inquiry, you need > > a device to do a path inquiry on. (i.e. path inquiries can only be done > > via the pass driver at the moment, they aren't supported through the xpt > > driver.) > > Any reason we can't do this through the xpt driver? I'll do it if no > objection. This would make some code I have for DUh identical in FreeBSD. I think it's fine to add a way to do it via the xpt driver. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 17 17:46:23 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.prod.itd.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id 3C6F637B61C for ; Sun, 17 Sep 2000 17:46:19 -0700 (PDT) Received: from veager.siteplus.net (user-38lc8kg.dialup.mindspring.com [209.86.34.144]) by scaup.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id RAA09701 for ; Sun, 17 Sep 2000 17:46:17 -0700 (PDT) Date: Sun, 17 Sep 2000 20:45:24 -0400 (EDT) From: Jim Weeks To: freebsd-scsi@freebsd.org Subject: umount -f question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am not sure if this is the right forum for this question but I haven't had a lot of help with this problem elsewhere. I have a Seagate Barracuda drive on a BT958 controller that dies during heavy writes. I have pretty much narrowed it down to outdated firm ware, but I have not been able to upgrade it yet. Right now it is down. I can stop, start, and tur it with camcontrol, but am unable to umount, mount, fsck, fdisk, or disklabel. I get device not configured errors. My question is why I cannot remove the mount point as listed in # df with the # umount -f /dev/da1s1e command. In the past I have been able to comment out the entry in /etc/fstab and reboot. Then I can run fsck by hand and remount the drive. Right now reboot is not an option. Any suggestions would be appreciated, -- Jim Weeks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 18 7: 8:43 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 08DF337B424 for ; Mon, 18 Sep 2000 07:08:35 -0700 (PDT) Received: (qmail 12798 invoked from network); 18 Sep 2000 14:08:30 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 18 Sep 2000 14:08:30 -0000 Date: Tue, 19 Sep 2000 01:08:26 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Jim Weeks Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: umount -f question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 17 Sep 2000, Jim Weeks wrote: > I am not sure if this is the right forum for this question but I haven't > had a lot of help with this problem elsewhere. > > I have a Seagate Barracuda drive on a BT958 controller that dies during > heavy writes. I have pretty much narrowed it down to outdated firm ware, > but I have not been able to upgrade it yet. > > Right now it is down. I can stop, start, and tur it with camcontrol, but > am unable to umount, mount, fsck, fdisk, or disklabel. I get device not > configured errors. > > My question is why I cannot remove the mount point as listed in # df with > the # umount -f /dev/da1s1e command. umount -f doesn't try hard enough to force the unmount, at least for ffs. ffs_unmount() uses the -f flag only for flushing files. Then, if the filesystems mounted rw, it always attempts to update the superblock, and this should always fail if the drive has died. I ignore errors from this in my version of ffs_vfsops.c (I should only ignore them in the -f case). If the superblock update succeeds, then ffs_unmount() is committed to the mount succeeding, but the unmount can still fail if closing the device fails, as probably happens if the device has died. This may cause memory leaks or worse because dounmount() doesn't understand half successful unmounts. Failure of the other commands is correct because they involve opens and the driver shouldn't allow opening dead devices. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 18 12:28:34 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.prod.itd.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 21CFD37B423 for ; Mon, 18 Sep 2000 12:28:32 -0700 (PDT) Received: from veager.siteplus.net (1Cust10.tnt10.chattanooga.tn.da.uu.net [63.22.145.10]) by falcon.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id MAA07476; Mon, 18 Sep 2000 12:28:18 -0700 (PDT) Date: Mon, 18 Sep 2000 15:28:11 -0400 (EDT) From: Jim Weeks To: Bruce Evans Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: umount -f question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 19 Sep 2000, Bruce Evans wrote: > umount -f doesn't try hard enough to force the unmount, at least for ffs. > ffs_unmount() uses the -f flag only for flushing files. Then, if the > filesystems mounted rw, it always attempts to update the superblock, and > this should always fail if the drive has died. I ignore errors from > this in my version of ffs_vfsops.c (I should only ignore them in the -f > case). If the superblock update succeeds, then ffs_unmount() is committed > to the mount succeeding, but the unmount can still fail if closing the > device fails, as probably happens if the device has died. This may cause > memory leaks or worse because dounmount() doesn't understand half > successful unmounts. > > Failure of the other commands is correct because they involve opens and > the driver shouldn't allow opening dead devices. > > Bruce Thanks for the insight. Then as I understand it there would be no way of freeing up the mount point as long as the drive is hung in this way? Since this is a production machine I couldn't afford to remote reboot untill someone was near the machine. After I did reboot I was able to fsck the disk and remount. These are the messages produced during fsck. # fsck /dev/da1s1e ** /dev/rda1s1e ** Last Mounted on /bak ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 103452 files, 1802476 used, 6892603 free (5251 frags, 860919 blocks, 0.1% fragme ntation) ***** FILE SYSTEM MARKED CLEAN ***** ***** FILE SYSTEM WAS MODIFIED ***** It is just hard to belive that there is no other way of getting back on track without a reboot. -- Jim Weeks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 18 16: 3:40 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.rdc1.az.home.com (ha1.rdc1.az.home.com [24.1.240.66]) by hub.freebsd.org (Postfix) with ESMTP id E29FB37B423 for ; Mon, 18 Sep 2000 16:03:37 -0700 (PDT) Received: from tjabring ([24.1.196.75]) by mail.rdc1.az.home.com (InterMail vM.4.01.02.00 201-229-116) with SMTP id <20000918230337.MGON12685.mail.rdc1.az.home.com@tjabring> for ; Mon, 18 Sep 2000 16:03:37 -0700 Message-ID: <000801c021c5$003d1190$020a0a0a@tjabring> From: "Kelsey Womack" To: Subject: Are there ANY scsi drives that dont screw up? Adaptec 39160's w/IBM DDYS-T09170N S80D Drives Date: Mon, 18 Sep 2000 16:05:56 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C0218A.53BB2130" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C0218A.53BB2130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ahc1: WARNING no command for scb 13 (cmdcmplt) QOUTPOS =3D 190 (da0:ahc1:0:0:0): SCB 0xb - timed out while idle, SEQADDR =3D=3D 0xc (da0:ahc1:0:0:0): Queuing a BDR SCB (da0:ahc1:0:0:0): Bus Device Reset Message Sent (da0:ahc1:0:0:0): no longer in timeout, status =3D 34b ahc1: Bus Device Reset on A:0. 1 SCBs aborted ahc1: WARNING no command for scb 122 (cmdcmplt) QOUTPOS =3D 124 (da0:ahc1:0:0:0): SCB 0x28 - timed out while idle, SEQADDR =3D=3D 0xa (da0:ahc1:0:0:0): Queuing a BDR SCB (da0:ahc1:0:0:0): Bus Device Reset Message Sent (da0:ahc1:0:0:0): no longer in timeout, status =3D 34b ahc1: Bus Device Reset on A:0. 1 SCBs aborted Any ideas? Should I update the firmware? And please tell me there's a = version I can use with FreeBSD... heheh -Kelsey ------=_NextPart_000_0005_01C0218A.53BB2130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
ahc1: WARNING no command for scb 13=20 (cmdcmplt)
QOUTPOS =3D 190
(da0:ahc1:0:0:0): SCB 0xb - timed out = while idle,=20 SEQADDR =3D=3D 0xc
(da0:ahc1:0:0:0): Queuing a BDR = SCB
(da0:ahc1:0:0:0): Bus=20 Device Reset Message Sent
(da0:ahc1:0:0:0): no longer in timeout, = status =3D=20 34b
ahc1: Bus Device Reset on A:0. 1 SCBs aborted
ahc1: WARNING no = command=20 for scb 122 (cmdcmplt)
QOUTPOS =3D 124
(da0:ahc1:0:0:0): SCB 0x28 = - timed=20 out while idle, SEQADDR =3D=3D 0xa
(da0:ahc1:0:0:0): Queuing a BDR=20 SCB
(da0:ahc1:0:0:0): Bus Device Reset Message = Sent
(da0:ahc1:0:0:0): no=20 longer in timeout, status =3D 34b
ahc1: Bus Device Reset on A:0. 1 = SCBs=20 aborted
 
Any ideas?  Should I update the=20 firmware?  And please tell me there's a version I can use with = FreeBSD...=20 heheh
 
   =20 -Kelsey
------=_NextPart_000_0005_01C0218A.53BB2130-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 18 16:10:38 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 298CD37B423 for ; Mon, 18 Sep 2000 16:10:36 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id RAA35040; Mon, 18 Sep 2000 17:10:32 -0600 (MDT) (envelope-from ken) Date: Mon, 18 Sep 2000 17:10:32 -0600 From: "Kenneth D. Merry" To: Kelsey Womack Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Are there ANY scsi drives that dont screw up? Adaptec 39160's w/IBM DDYS-T09170N S80D Drives Message-ID: <20000918171032.A34984@panzer.kdm.org> References: <000801c021c5$003d1190$020a0a0a@tjabring> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <000801c021c5$003d1190$020a0a0a@tjabring>; from kelseywomack@home.com on Mon, Sep 18, 2000 at 04:05:56PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Sep 18, 2000 at 16:05:56 -0700, Kelsey Womack wrote: > ahc1: WARNING no command for scb 13 (cmdcmplt) > QOUTPOS = 190 > (da0:ahc1:0:0:0): SCB 0xb - timed out while idle, SEQADDR == 0xc > (da0:ahc1:0:0:0): Queuing a BDR SCB > (da0:ahc1:0:0:0): Bus Device Reset Message Sent > (da0:ahc1:0:0:0): no longer in timeout, status = 34b > ahc1: Bus Device Reset on A:0. 1 SCBs aborted > ahc1: WARNING no command for scb 122 (cmdcmplt) > QOUTPOS = 124 > (da0:ahc1:0:0:0): SCB 0x28 - timed out while idle, SEQADDR == 0xa > (da0:ahc1:0:0:0): Queuing a BDR SCB > (da0:ahc1:0:0:0): Bus Device Reset Message Sent > (da0:ahc1:0:0:0): no longer in timeout, status = 34b > ahc1: Bus Device Reset on A:0. 1 SCBs aborted > > Any ideas? Should I update the firmware? And please tell me there's a version I can use with FreeBSD... heheh > [ make sure you wrap your lines at 70 columns or so, it's easier to read ] Yes, you should update the firmware. From the subject, you're using version S80D of the firmware, which I have heard (second hand) can lock up the bus. FWIW, I've got two 36G DDYS drives with the same firmware. I haven't had lockups, but then I don't push them very hard. Supposedly the problems are fixed in version S93E of the firmware for the DDYS drives. (And this problem only affects the DDYS drives.) I don't have the firmware, you'll probably need to talk to IBM about getting it. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 18 17:12:37 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 3E33337B423 for ; Mon, 18 Sep 2000 17:12:30 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id SAA35620; Mon, 18 Sep 2000 18:07:25 -0600 (MDT) (envelope-from ken) Date: Mon, 18 Sep 2000 18:07:25 -0600 From: "Kenneth D. Merry" To: Kelsey Womack Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Are there ANY scsi drives that dont screw up? Adaptec 39160's w/IBM DDYS-T09170N S80D Drives Message-ID: <20000918180725.A35596@panzer.kdm.org> References: <000801c021c5$003d1190$020a0a0a@tjabring> <20000918171032.A34984@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000918171032.A34984@panzer.kdm.org>; from ken@kdm.org on Mon, Sep 18, 2000 at 05:10:32PM -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Sep 18, 2000 at 17:10:32 -0600, Kenneth D. Merry wrote: > On Mon, Sep 18, 2000 at 16:05:56 -0700, Kelsey Womack wrote: > > ahc1: WARNING no command for scb 13 (cmdcmplt) > > QOUTPOS = 190 > > (da0:ahc1:0:0:0): SCB 0xb - timed out while idle, SEQADDR == 0xc > > (da0:ahc1:0:0:0): Queuing a BDR SCB > > (da0:ahc1:0:0:0): Bus Device Reset Message Sent > > (da0:ahc1:0:0:0): no longer in timeout, status = 34b > > ahc1: Bus Device Reset on A:0. 1 SCBs aborted > > ahc1: WARNING no command for scb 122 (cmdcmplt) > > QOUTPOS = 124 > > (da0:ahc1:0:0:0): SCB 0x28 - timed out while idle, SEQADDR == 0xa > > (da0:ahc1:0:0:0): Queuing a BDR SCB > > (da0:ahc1:0:0:0): Bus Device Reset Message Sent > > (da0:ahc1:0:0:0): no longer in timeout, status = 34b > > ahc1: Bus Device Reset on A:0. 1 SCBs aborted > > > > Any ideas? Should I update the firmware? And please tell me there's a version I can use with FreeBSD... heheh > > > [ make sure you wrap your lines at 70 columns or so, it's easier to read ] > > Yes, you should update the firmware. From the subject, you're using > version S80D of the firmware, which I have heard (second hand) can lock up > the bus. FWIW, I've got two 36G DDYS drives with the same firmware. I > haven't had lockups, but then I don't push them very hard. > > Supposedly the problems are fixed in version S93E of the firmware for the > DDYS drives. (And this problem only affects the DDYS drives.) Actually, it looks like the problems also affect the DPSS drives, which are the Ultrastar 36LP 7200RPM series. So if you've got any of those, you'll want to upgrade the firmware for them as well. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Sep 19 1:22:54 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id A4BE437B422 for ; Tue, 19 Sep 2000 01:22:51 -0700 (PDT) Received: (qmail 76879 invoked by uid 1001); 19 Sep 2000 08:22:49 +0000 (GMT) To: ken@kdm.org Cc: kelseywomack@home.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Are there ANY scsi drives that dont screw up? Adaptec 39160's w/IBM DDYS-T09170N S80D Drives From: sthaug@nethelp.no In-Reply-To: Your message of "Mon, 18 Sep 2000 17:10:32 -0600" References: <20000918171032.A34984@panzer.kdm.org> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 19 Sep 2000 10:22:49 +0200 Message-ID: <76877.969351769@verdi.nethelp.no> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Yes, you should update the firmware. From the subject, you're using > version S80D of the firmware, which I have heard (second hand) can lock up > the bus. FWIW, I've got two 36G DDYS drives with the same firmware. I > haven't had lockups, but then I don't push them very hard. In the same vein - does anybody know if there are any firmware issues with these IBM 36 GB drives: da2: Fixed Direct Access SCSI-3 device Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Sep 19 5:42:20 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from theshell.com (arsenic.theshell.com [63.236.138.5]) by hub.freebsd.org (Postfix) with SMTP id 3414437B509 for ; Tue, 19 Sep 2000 05:41:28 -0700 (PDT) Received: (qmail 29990 invoked from network); 19 Sep 2000 12:41:16 -0000 Received: from arsenic.theshell.com (HELO tequila) (root@63.236.138.5) by arsenic.theshell.com with SMTP; 19 Sep 2000 12:41:16 -0000 From: "Peter Avalos" To: "freebsd-scsi@FreeBSD. ORG" Subject: RE: Are there ANY scsi drives that dont screw up? Adaptec 39160's w/IBM DDYS-T09170N S80D Drives Date: Tue, 19 Sep 2000 07:44:26 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20000918180725.A35596@panzer.kdm.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Everyone keeps talking about updating firmware, but I can't find the firmware upgrades anywhere on ibm's site. How do you go about doing this? Peter Avalos -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/ED/B d-(+) s:+> a-- C++$ UBLO++++$ P+ L++++ E- W+ N+ o? K? w(++) !O M- V- PS+ PE++ Y+ PGP++ t+@ 5 X- R- tv+ b++ DI- D-- G e>+++ h-- r++ y++ ------END GEEK CODE BLOCK------ > -----Original Message----- > From: owner-freebsd-scsi@FreeBSD.ORG > [mailto:owner-freebsd-scsi@FreeBSD.ORG]On Behalf Of Kenneth D. Merry > Sent: Monday, September 18, 2000 7:07 PM > To: Kelsey Womack > Cc: freebsd-scsi@FreeBSD.ORG > Subject: Re: Are there ANY scsi drives that dont screw up? Adaptec > 39160's w/IBM DDYS-T09170N S80D Drives > > > On Mon, Sep 18, 2000 at 17:10:32 -0600, Kenneth D. Merry wrote: > > On Mon, Sep 18, 2000 at 16:05:56 -0700, Kelsey Womack wrote: > > > ahc1: WARNING no command for scb 13 (cmdcmplt) > > > QOUTPOS = 190 > > > (da0:ahc1:0:0:0): SCB 0xb - timed out while idle, SEQADDR == 0xc > > > (da0:ahc1:0:0:0): Queuing a BDR SCB > > > (da0:ahc1:0:0:0): Bus Device Reset Message Sent > > > (da0:ahc1:0:0:0): no longer in timeout, status = 34b > > > ahc1: Bus Device Reset on A:0. 1 SCBs aborted > > > ahc1: WARNING no command for scb 122 (cmdcmplt) > > > QOUTPOS = 124 > > > (da0:ahc1:0:0:0): SCB 0x28 - timed out while idle, SEQADDR == 0xa > > > (da0:ahc1:0:0:0): Queuing a BDR SCB > > > (da0:ahc1:0:0:0): Bus Device Reset Message Sent > > > (da0:ahc1:0:0:0): no longer in timeout, status = 34b > > > ahc1: Bus Device Reset on A:0. 1 SCBs aborted > > > > > > Any ideas? Should I update the firmware? And please tell me > there's a version I can use with FreeBSD... heheh > > > > > [ make sure you wrap your lines at 70 columns or so, it's > easier to read ] > > > > Yes, you should update the firmware. From the subject, you're using > > version S80D of the firmware, which I have heard (second hand) > can lock up > > the bus. FWIW, I've got two 36G DDYS drives with the same firmware. I > > haven't had lockups, but then I don't push them very hard. > > > > Supposedly the problems are fixed in version S93E of the > firmware for the > > DDYS drives. (And this problem only affects the DDYS drives.) > > Actually, it looks like the problems also affect the DPSS drives, > which are > the Ultrastar 36LP 7200RPM series. So if you've got any of those, you'll > want to upgrade the firmware for them as well. > > Ken > -- > Kenneth Merry > ken@kdm.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Sep 19 9:41:34 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.rdc1.az.home.com (ha1.rdc1.az.home.com [24.1.240.66]) by hub.freebsd.org (Postfix) with ESMTP id E404E37B424 for ; Tue, 19 Sep 2000 09:41:27 -0700 (PDT) Received: from tjabring ([24.1.196.75]) by mail.rdc1.az.home.com (InterMail vM.4.01.02.00 201-229-116) with SMTP id <20000919164126.BNAB12685.mail.rdc1.az.home.com@tjabring>; Tue, 19 Sep 2000 09:41:26 -0700 Message-ID: <000a01c02258$c7ba5dc0$020a0a0a@tjabring> From: "Kelsey Womack" To: "Peter Avalos" Cc: References: Subject: Re: Are there ANY scsi drives that dont screw up? Adaptec 39160's w/IBM DDYS-T09170N S80D Drives Date: Tue, 19 Sep 2000 09:43:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You have to call them up and tell them your problem, then they will 'attempt' to contact you. When I talked with them, they said they needed some form of proof, incase you are someone who doesn't know what they are doing, who just wants the latest firmware :-( Anyhow, I'm still waiting for them to contact me. 1-888-IBM-5214 is their number, then 2 for technical support. -Kelsey ----- Original Message ----- From: "Peter Avalos" To: "freebsd-scsi@FreeBSD. ORG" Sent: Tuesday, September 19, 2000 5:44 AM Subject: RE: Are there ANY scsi drives that dont screw up? Adaptec 39160's w/IBM DDYS-T09170N S80D Drives > Everyone keeps talking about updating firmware, but I can't find the > firmware upgrades anywhere on ibm's site. How do you go about doing this? > > > Peter Avalos > > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCS/ED/B d-(+) s:+> a-- C++$ UBLO++++$ P+ L++++ E- W+ N+ o? K? w(++) !O M- > V- PS+ PE++ Y+ PGP++ t+@ 5 X- R- tv+ b++ DI- D-- G e>+++ h-- r++ y++ > ------END GEEK CODE BLOCK------ > > > -----Original Message----- > > From: owner-freebsd-scsi@FreeBSD.ORG > > [mailto:owner-freebsd-scsi@FreeBSD.ORG]On Behalf Of Kenneth D. Merry > > Sent: Monday, September 18, 2000 7:07 PM > > To: Kelsey Womack > > Cc: freebsd-scsi@FreeBSD.ORG > > Subject: Re: Are there ANY scsi drives that dont screw up? Adaptec > > 39160's w/IBM DDYS-T09170N S80D Drives > > > > > > On Mon, Sep 18, 2000 at 17:10:32 -0600, Kenneth D. Merry wrote: > > > On Mon, Sep 18, 2000 at 16:05:56 -0700, Kelsey Womack wrote: > > > > ahc1: WARNING no command for scb 13 (cmdcmplt) > > > > QOUTPOS = 190 > > > > (da0:ahc1:0:0:0): SCB 0xb - timed out while idle, SEQADDR == 0xc > > > > (da0:ahc1:0:0:0): Queuing a BDR SCB > > > > (da0:ahc1:0:0:0): Bus Device Reset Message Sent > > > > (da0:ahc1:0:0:0): no longer in timeout, status = 34b > > > > ahc1: Bus Device Reset on A:0. 1 SCBs aborted > > > > ahc1: WARNING no command for scb 122 (cmdcmplt) > > > > QOUTPOS = 124 > > > > (da0:ahc1:0:0:0): SCB 0x28 - timed out while idle, SEQADDR == 0xa > > > > (da0:ahc1:0:0:0): Queuing a BDR SCB > > > > (da0:ahc1:0:0:0): Bus Device Reset Message Sent > > > > (da0:ahc1:0:0:0): no longer in timeout, status = 34b > > > > ahc1: Bus Device Reset on A:0. 1 SCBs aborted > > > > > > > > Any ideas? Should I update the firmware? And please tell me > > there's a version I can use with FreeBSD... heheh > > > > > > > [ make sure you wrap your lines at 70 columns or so, it's > > easier to read ] > > > > > > Yes, you should update the firmware. From the subject, you're using > > > version S80D of the firmware, which I have heard (second hand) > > can lock up > > > the bus. FWIW, I've got two 36G DDYS drives with the same firmware. I > > > haven't had lockups, but then I don't push them very hard. > > > > > > Supposedly the problems are fixed in version S93E of the > > firmware for the > > > DDYS drives. (And this problem only affects the DDYS drives.) > > > > Actually, it looks like the problems also affect the DPSS drives, > > which are > > the Ultrastar 36LP 7200RPM series. So if you've got any of those, you'll > > want to upgrade the firmware for them as well. > > > > Ken > > -- > > Kenneth Merry > > ken@kdm.org > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-scsi" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Sep 19 18:20:16 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from cs4.cs.ait.ac.th (cs4.cs.ait.ac.th [192.41.170.15]) by hub.freebsd.org (Postfix) with ESMTP id 6F84E37B422 for ; Tue, 19 Sep 2000 18:20:11 -0700 (PDT) Received: from banyan.cs.ait.ac.th (on@banyan.cs.ait.ac.th [192.41.170.5]) by cs4.cs.ait.ac.th (8.9.3/8.9.3) with ESMTP id IAA20021 for ; Wed, 20 Sep 2000 08:20:02 +0700 (GMT+0700) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.8.5/8.8.5) id IAA01992; Wed, 20 Sep 2000 08:20:01 +0700 (ICT) Date: Wed, 20 Sep 2000 08:20:01 +0700 (ICT) Message-Id: <200009200120.IAA01992@banyan.cs.ait.ac.th> X-Authentication-Warning: banyan.cs.ait.ac.th: on set sender to on@banyan.cs.ait.ac.th using -f From: Olivier Nicole To: freebsd-scsi@FreeBSD.ORG Subject: Adaptec with what mother board? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I wonder if anyone has information about the compatibility of "Aopen" motherboard DX3R Plus with Adaptec 29160. Thank you, Olivier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Sep 19 20:16:40 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by hub.freebsd.org (Postfix) with ESMTP id 1B51937B422 for ; Tue, 19 Sep 2000 20:16:36 -0700 (PDT) Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp (Exim 3.12 #7) id 13baN7-000011-00; Wed, 20 Sep 2000 03:16:33 +0000 Received: from sdn-ar-008florlap277.dialsprint.net ([206.133.84.79] helo=magicnet.net) by dfw-mmp3.email.verio.net with esmtp (Exim 3.15 #4) id 13baN6-0003yE-00; Wed, 20 Sep 2000 03:16:32 +0000 Message-ID: <39C82BEF.2BCA02C4@magicnet.net> Date: Tue, 19 Sep 2000 23:15:59 -0400 From: Steven Bradley Reply-To: steven@magicnet.net Organization: http://www.magicnet.net/~steven X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Kelsey Womack , freebsd-scsi@freebsd.org Subject: Re: Are there ANY scsi drives that dont screw up? Adaptec 39160's w/IBM DDYS-T09170N S80D Drives References: <000801c021c5$003d1190$020a0a0a@tjabring> Content-Type: multipart/alternative; boundary="------------111037FFBFC0573298E86665" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --------------111037FFBFC0573298E86665 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit For whatever it is worth, I tried to install the current version of FreeBSD a few weeks ago from boot disk(s). After the second disk was fed, it gave similiar output and I never did find out why. That was why I subscribed to this listserve. I am using an old Adaptec 1542B for those interested and only use SCSI in my system (three of them, two inside, one external). I gave up and went to Red Hat 6.1 which worked perfectly and has not failed me in that respect. When the boot disk does not successfully boot, I considered that a bad omen and time to find an OS that would correctly do so. I did try a few things and the results were always the same. RH on the other hand has never failed (in that manner, I have had a few other strange experiences, it took a week to get my PAS16 sound card running for example, but it is - just poor to terrible (non-existant) documentation was part of that problem and the other was the lp interface, same problem, it did not auto install it and the docs were poor to non-existant). Sorry this does not help -- but I thought the card (due to it's age and reputation to be "the card" of preference for Unix systems (at one time)) may be of some significant help. Steven Kelsey Womack wrote: > ahc1: WARNING no command for scb 13 (cmdcmplt) > QOUTPOS = 190 > (da0:ahc1:0:0:0): SCB 0xb - timed out while idle, SEQADDR == 0xc > (da0:ahc1:0:0:0): Queuing a BDR SCB > (da0:ahc1:0:0:0): Bus Device Reset Message Sent > (da0:ahc1:0:0:0): no longer in timeout, status = 34b > ahc1: Bus Device Reset on A:0. 1 SCBs aborted > ahc1: WARNING no command for scb 122 (cmdcmplt) > QOUTPOS = 124 > (da0:ahc1:0:0:0): SCB 0x28 - timed out while idle, SEQADDR == 0xa > (da0:ahc1:0:0:0): Queuing a BDR SCB > (da0:ahc1:0:0:0): Bus Device Reset Message Sent > (da0:ahc1:0:0:0): no longer in timeout, status = 34b > ahc1: Bus Device Reset on A:0. 1 SCBs aborted Any ideas? Should I > update the firmware? And please tell me there's a version I can use > with FreeBSD... heheh -Kelsey -- Steven Bradley 121 Cambridge Drive steven@magicnet.net Longwood, FL 32779-5707 USA CompuServe: 102555,3031 Tel: (407) 862-7226 URL: http://www.magicnet.net/~steven Pager: (407) 231-4325 "And He said to them, "Go into all the world and preach the gospel to all creation". Mark 16:15 --------------111037FFBFC0573298E86665 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit For whatever it is worth, I tried to install the current version of FreeBSD a few weeks ago from boot disk(s).  After the second disk was fed, it gave similiar output and I never did find out why.

That was why I subscribed to this listserve.  I am using an old Adaptec 1542B for those interested and only use SCSI in my system (three of them, two inside, one external).

I gave up and went to Red Hat 6.1 which worked perfectly and has not failed me in that respect.

When the boot disk does not successfully boot, I considered that a bad omen and time to find an OS that would correctly do so.  I did try a few things and the results were always the same.  RH on the other hand has never failed (in that manner, I have had a few other strange experiences, it took a week to get my PAS16 sound card running for example, but it is - just poor to terrible (non-existant) documentation was part of that problem and the other was the lp interface, same problem, it did not auto install it and the docs were poor to non-existant).

Sorry this does not help -- but I thought the card (due to it's age and reputation to be "the card" of preference for Unix systems (at one time)) may be of some significant help.

Steven

Kelsey Womack wrote:

ahc1: WARNING no command for scb 13 (cmdcmplt)
QOUTPOS = 190
(da0:ahc1:0:0:0): SCB 0xb - timed out while idle, SEQADDR == 0xc
(da0:ahc1:0:0:0): Queuing a BDR SCB
(da0:ahc1:0:0:0): Bus Device Reset Message Sent
(da0:ahc1:0:0:0): no longer in timeout, status = 34b
ahc1: Bus Device Reset on A:0. 1 SCBs aborted
ahc1: WARNING no command for scb 122 (cmdcmplt)
QOUTPOS = 124
(da0:ahc1:0:0:0): SCB 0x28 - timed out while idle, SEQADDR == 0xa
(da0:ahc1:0:0:0): Queuing a BDR SCB
(da0:ahc1:0:0:0): Bus Device Reset Message Sent
(da0:ahc1:0:0:0): no longer in timeout, status = 34b
ahc1: Bus Device Reset on A:0. 1 SCBs aborted Any ideas?  Should I update the firmware?  And please tell me there's a version I can use with FreeBSD... heheh     -Kelsey

--
Steven Bradley                                      121 Cambridge Drive
steven@magicnet.net                         Longwood, FL 32779-5707 USA
CompuServe: 102555,3031                             Tel: (407) 862-7226
URL: http://www.magicnet.net/~steven              Pager: (407) 231-4325

"And He said to them, "Go into all the world and preach the gospel to all creation". Mark 16:15
  --------------111037FFBFC0573298E86665-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 20 7:24:56 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.quantum.com (mx1.quantum.com [204.212.103.34]) by hub.freebsd.org (Postfix) with ESMTP id 2E3F437B422; Wed, 20 Sep 2000 07:24:51 -0700 (PDT) Received: from milcmima.qntm.com (milcmima.qntm.com [146.174.18.61]) by mx1.quantum.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id HAA11704; Wed, 20 Sep 2000 07:24:49 -0700 (PDT) Received: by milcmima.qntm.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Sep 2000 07:24:46 -0700 Message-ID: <8133266FE373D11190CD00805FA768BF055BD1C9@shrcmsg1.tdh.qntm.com> From: Stephen Byan To: fs@FreeBSD.ORG Cc: sos@FreeBSD.ORG, "'freeBSD-scsi@freeBSD.org'" Subject: RE: disable write caching with softupdates? Date: Wed, 20 Sep 2000 07:24:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert [mailto:tlambert@primenet.com] wrote: > > Isn't it safer (in the face of a power failure) to disable write > > caching on a hard disk when softupdates is in use? > > Yes. You _must_ guarantee that the drive does not complete > writes out of sequence that it reports having completed in > sequence. Hardware which lies is evil. > > > > The ata driver currenly always enables write caching. Perhaps > > there should be a sysctl knob to turn it on/off? > > Write caching should _never_ be enabled, unless you don't > care about the data, or the drive reports the operation > queueing and completion seperately, so that the OS knows > the completion order; even then, the OS will have to be > prepared to stall writing new data until completion has > occurred at any given synchronizatin point, so that it is > impossible for the drive to complete the requests out of > the order permitted by the OS. > > With regard to "_never_": even a sync mounted FS will not > be recoverable to a deterministic state if write caching > does not guarantee completion in FIFO order, for obvious > reasons -- it doesn't matter if you go async in the kernel, > or async in the drive, either way your data gets screwed. Wouldn't it be acceptable to mark the meta-data writes as non-cacheable (i.e. write though to the media before signalling completion), and let the remaining writes (user data writes) be cacheable? I think this would improve the performance of the file system. SCSI has supported this for years, in the form of the FUA bit in the CDB for the write command. Somewhat similar behavior can be had in the newer flavors of ATA by issuing a "flush cache" command after each meta-data write, and waiting until the flush command completes before signalling the completion of the non-cacheable write. Regards, -Steve Steve Byan Design Engineer MS 1-3/E23 333 South Street Shrewsbury, MA 01545 (508)770-3414 fax: (508)770-2604 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 20 18:27:13 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from cs4.cs.ait.ac.th (cs4.cs.ait.ac.th [192.41.170.15]) by hub.freebsd.org (Postfix) with ESMTP id 88BB937B43C for ; Wed, 20 Sep 2000 18:27:08 -0700 (PDT) Received: from banyan.cs.ait.ac.th (on@banyan.cs.ait.ac.th [192.41.170.5]) by cs4.cs.ait.ac.th (8.9.3/8.9.3) with ESMTP id IAA27499 for ; Thu, 21 Sep 2000 08:27:03 +0700 (GMT+0700) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.8.5/8.8.5) id IAA04342; Thu, 21 Sep 2000 08:27:01 +0700 (ICT) Date: Thu, 21 Sep 2000 08:27:01 +0700 (ICT) Message-Id: <200009210127.IAA04342@banyan.cs.ait.ac.th> X-Authentication-Warning: banyan.cs.ait.ac.th: on set sender to on@banyan.cs.ait.ac.th using -f From: Olivier Nicole To: freebsd-scsi@FreeBSD.ORG Subject: SCSI U160? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --text follows this line-- Hello, Another enquiry, does any of you can confirm that Asus MortherBoard CUR-DLS ServerWorks ServerSet III LE 3.0, based on ServerSetIII LE chipset and that includes dual channel U160 is working? ServerSetIII LE 3.0 chipset is based on NB6635 NorthBridge 3.0 LE with 576 Tape Bal Grid Array (TBGA) and IB6566 South Bridge with 352 Plastic Ball Grid Array (PBGA) [and don't ask me what are TBGA or PBGA] Thank you, Olivier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 1:24:12 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id B16BE37B50D; Thu, 21 Sep 2000 01:24:07 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id KAA98478; Thu, 21 Sep 2000 10:25:00 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <200009210825.KAA98478@freebsd.dk> Subject: Re: disable write caching with softupdates? In-Reply-To: <8133266FE373D11190CD00805FA768BF055BD1C9@shrcmsg1.tdh.qntm.com> from Stephen Byan at "Sep 20, 2000 07:24:44 am" To: Stephen.Byan@quantum.com (Stephen Byan) Date: Thu, 21 Sep 2000 10:25:00 +0200 (CEST) Cc: fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG ('freeBSD-scsi@freeBSD.org') X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It seems Stephen Byan wrote: > > > > Write caching should _never_ be enabled, unless you don't > > care about the data, or the drive reports the operation > > queueing and completion seperately, so that the OS knows > > the completion order; even then, the OS will have to be > > prepared to stall writing new data until completion has > > occurred at any given synchronizatin point, so that it is > > impossible for the drive to complete the requests out of > > the order permitted by the OS. > > > > With regard to "_never_": even a sync mounted FS will not > > be recoverable to a deterministic state if write caching > > does not guarantee completion in FIFO order, for obvious > > reasons -- it doesn't matter if you go async in the kernel, > > or async in the drive, either way your data gets screwed. > > Wouldn't it be acceptable to mark the meta-data writes as non-cacheable > (i.e. write though to the media before signalling completion), and let the > remaining writes (user data writes) be cacheable? I think this would improve > the performance of the file system. > > SCSI has supported this for years, in the form of the FUA bit in the CDB for > the write command. Somewhat similar behavior can be had in the newer flavors > of ATA by issuing a "flush cache" command after each meta-data write, and > waiting until the flush command completes before signalling the completion > of the non-cacheable write. OK, I played a bit with that, the only info I can see I get from the higher levels is the BIO_ORDERED bit, so I tried to flush the cache each time I get one of those, _bad_ idea, 10% performance loss... Suggestions are welcome :) -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 4:48:55 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 7C34F37B42C; Thu, 21 Sep 2000 04:48:51 -0700 (PDT) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id NAA58037; Thu, 21 Sep 2000 13:48:49 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id NAA38177; Thu, 21 Sep 2000 13:48:49 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Thu, 21 Sep 2000 13:48:49 +0200 (CEST) From: Marius Bendiksen To: Stephen Byan Cc: fs@FreeBSD.ORG, sos@FreeBSD.ORG, "'freeBSD-scsi@freeBSD.org'" Subject: RE: disable write caching with softupdates? In-Reply-To: <8133266FE373D11190CD00805FA768BF055BD1C9@shrcmsg1.tdh.qntm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Wouldn't it be acceptable to mark the meta-data writes as non-cacheable > (i.e. write though to the media before signalling completion), and let the > remaining writes (user data writes) be cacheable? I think this would improve > the performance of the file system. Actually, performance-wise, you'd probably want to know the real geometry, given all the stuff FFS does to exploit it. > SCSI has supported this for years, in the form of the FUA bit in the CDB for > the write command. Somewhat similar behavior can be had in the newer flavors As I recall, and from what Eivind noted, this bit is routinely ignored in about 90% of all drives out there. > of ATA by issuing a "flush cache" command after each meta-data write, and > waiting until the flush command completes before signalling the completion > of the non-cacheable write. This has the potential for degrading performance even further. I think you would prefer to disable cache over this. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 6:11:15 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.quantum.com (mx1.quantum.com [204.212.103.34]) by hub.freebsd.org (Postfix) with ESMTP id B727837B422; Thu, 21 Sep 2000 06:11:11 -0700 (PDT) Received: from milcmima.qntm.com (milcmima.qntm.com [146.174.18.61]) by mx1.quantum.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id GAA16241; Thu, 21 Sep 2000 06:09:52 -0700 (PDT) Received: by milcmima.qntm.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Sep 2000 06:09:49 -0700 Message-ID: <8133266FE373D11190CD00805FA768BF055BD1D3@shrcmsg1.tdh.qntm.com> From: Stephen Byan To: "'Soren Schmidt'" , Stephen Byan Cc: fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG Subject: RE: disable write caching with softupdates? Date: Thu, 21 Sep 2000 06:09:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Soren Schmidt [mailto:sos@freebsd.dk] wrote: > > Wouldn't it be acceptable to mark the meta-data writes as > non-cacheable > > (i.e. write though to the media before signalling > completion), and let the > > remaining writes (user data writes) be cacheable? I think > this would improve > > the performance of the file system. > > > > SCSI has supported this for years, in the form of the FUA > bit in the CDB for > > the write command. Somewhat similar behavior can be had in > the newer flavors > > of ATA by issuing a "flush cache" command after each > meta-data write, and > > waiting until the flush command completes before signalling > the completion > > of the non-cacheable write. > > OK, I played a bit with that, the only info I can see I get from the > higher levels is the BIO_ORDERED bit, so I tried to flush the cache > each time I get one of those, _bad_ idea, 10% performance loss... That's the price of having a recoverable file system. See Seltzer, Ganger, McKusick, Smith, Soules, and Stein, "Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems", 2000 USENIX Annual Technical Conference, June 2000, San Diego. Contrast this 10% performance hit versus what you get when you disable caching entirely. Regards, -Steve Steve Byan Design Engineer MS 1-3/E23 333 South Street Shrewsbury, MA 01545 (508)770-3414 fax: (508)770-2604 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 6:38:44 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id DE10837B423; Thu, 21 Sep 2000 06:38:38 -0700 (PDT) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id PAA89799; Thu, 21 Sep 2000 15:38:37 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id PAA38975; Thu, 21 Sep 2000 15:38:36 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Thu, 21 Sep 2000 15:38:36 +0200 (CEST) From: Marius Bendiksen To: Stephen Byan Cc: "'Soren Schmidt'" , fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG Subject: RE: disable write caching with softupdates? In-Reply-To: <8133266FE373D11190CD00805FA768BF055BD1D3@shrcmsg1.tdh.qntm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > OK, I played a bit with that, the only info I can see I get from the > > higher levels is the BIO_ORDERED bit, so I tried to flush the cache > > each time I get one of those, _bad_ idea, 10% performance loss... > That's the price of having a recoverable file system. See Seltzer, Ganger, Not necessarily. > Contrast this 10% performance hit versus what you get when you disable > caching entirely. I think you will see that on some drives, this may have a greater performance impact than not caching at all. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 6:40:40 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.quantum.com (mx1.quantum.com [204.212.103.34]) by hub.freebsd.org (Postfix) with ESMTP id 1BBED37B422; Thu, 21 Sep 2000 06:40:34 -0700 (PDT) Received: from milcmima.qntm.com (milcmima.qntm.com [146.174.18.61]) by mx1.quantum.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id GAA20537; Thu, 21 Sep 2000 06:40:27 -0700 (PDT) Received: by milcmima.qntm.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Sep 2000 06:40:25 -0700 Message-ID: <8133266FE373D11190CD00805FA768BF055BD1D4@shrcmsg1.tdh.qntm.com> From: Stephen Byan To: "'Marius Bendiksen'" , Stephen Byan Cc: fs@FreeBSD.ORG, sos@FreeBSD.ORG, "'freeBSD-scsi@freeBSD.org'" Subject: RE: disable write caching with softupdates? Date: Thu, 21 Sep 2000 06:40:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Marius Bendiksen [mailto:mbendiks@eunet.no] wrote: > > Wouldn't it be acceptable to mark the meta-data writes as > non-cacheable > > (i.e. write though to the media before signalling > completion), and let the > > remaining writes (user data writes) be cacheable? I think > this would improve > > the performance of the file system. > > Actually, performance-wise, you'd probably want to know the > real geometry, > given all the stuff FFS does to exploit it. I think this is a separate issue, but: The problem with exposing the disk geometry is that FFS makes assumptions about the geometry that are false. Disks are zoned, so there aren't a constant number of sectors per track. Due to defects, the number of sectors per zone varies from sample to sample. It's possible that each surface in the drive has a different number of cylinders. In future disk generations, the geometry may get warped in unpredictable ways. Moreover, to take advantage of the geometry, the file system needs an accurate access time model. The constants in this model may vary from sample to sample of the same type of drive, and may vary due to environment conditions like temperature and power supply voltage. (Many of the access time optimization algorithms in the drives do in fact adapt to these variations.) The characteristics of the model vary widely between different designs of drives. So it's hard to envision a standard way of expressing the actual drive geometry and access time model to the file system. > > SCSI has supported this for years, in the form of the FUA > bit in the CDB for > > the write command. Somewhat similar behavior can be had in > the newer flavors > > As I recall, and from what Eivind noted, this bit is > routinely ignored in > about 90% of all drives out there. If you are referring to the SCSI FUA bit, this is absolutely untrue. All Quantum SCSI drives obey this bit. All currently-manufactured drives obey this bit. I believe 99% of the drives that claim compliance with the SCSI SBC spec do in fact obey the FUA bit on writes. There was a recent case where one manufacturer appears to have cheated and ignored this bit, and caught quite a bit of abuse for it. Like lost business from major OEMs. If you are referring to the flush cache command for ATA drives, you may have a point. For ATA drives, earlier versions of the ATA spec did not specify a way to flush the cache. The ATA driver in Windows NT appears to have implemented one vendor's vendor-unique command to flush the cache, which is not widely-supported and which has been superceded by a standard "flush cache" command in the newer versions of the ATA specification. > > of ATA by issuing a "flush cache" command after each > meta-data write, and > > waiting until the flush command completes before signalling > the completion > > of the non-cacheable write. > > This has the potential for degrading performance even > further. I think you > would prefer to disable cache over this. I agree, flushing the write cache could be painful. I don't see how it could be much worse than disabling the cache, since the disk's write cache is not lazily written, and so does not usually have much dirty data. Without write caching, you pay one disk rotation for each sequential write. In workloads with a moderate to high sequential write component, this is an extreme penalty. Also, with caching enabled, the disk does a fair amount of reordering to optimize the total seek and rotational cost of the writes. You give this up when disabling the write cache. Regards, -Steve Steve Byan Design Engineer MS 1-3/E23 333 South Street Shrewsbury, MA 01545 (508)770-3414 fax: (508)770-2604 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 6:51:23 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from weirdo.netcraft.com (weirdo.netcraft.com [195.188.192.47]) by hub.freebsd.org (Postfix) with ESMTP id 9D66437B42C for ; Thu, 21 Sep 2000 06:51:21 -0700 (PDT) Received: (from sketchy@localhost) by weirdo.netcraft.com (8.11.0/8.11.0) id e8LDpIC70282 for freebsd-scsi@freebsd.org; Thu, 21 Sep 2000 14:51:18 +0100 (BST) (envelope-from sketchy) Date: Thu, 21 Sep 2000 14:51:18 +0100 From: Jonathan Perkin To: freebsd-scsi@freebsd.org Subject: sys/dev/aic7xxx MFC Message-ID: <20000921145118.J215@netcraft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey guys. Recently there have been quite a few reports of breakage with 29160/7892 ahc and Supermicro combinations, of which most are fixed in -current. For those of us running -stable, is there likelyhood of an MFC soon (preferably before the 4.1.1 point release), or does anyone have homebrew patches to fix the reported problems? At the present time, our brand new server is running an old DPT SmartRAID-IV card due to the onboard 7892 being effectively redundant. If nobody's either made their own patches or Justin isn't likely to MFC soon (glancing through the -current driver it looks like a big job), I'll have a go at doing it myself - I'd just like to know that I'm not repeating any work first :) (For reference, the system is Supermicro 370DLE Dual 667MHz P3, Adaptec 7892 on-board, and Seagate ST39236LW/ST173404LW drives - showing the SCB resets/QUOTPOS errors which render a 4.1-R install impossible) Cheers. -- Jonathan Perkin Voice: +44 (01225) 404422 ech`echo xiun | tr nu oc | sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol System Administrator - Netcraft, Bath, UK - http://www.netcraft.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 7:10: 7 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.quantum.com (mx1.quantum.com [204.212.103.34]) by hub.freebsd.org (Postfix) with ESMTP id B8ADE37B423; Thu, 21 Sep 2000 07:10:01 -0700 (PDT) Received: from milcmima.qntm.com (milcmima.qntm.com [146.174.18.61]) by mx1.quantum.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id HAA25113; Thu, 21 Sep 2000 07:08:41 -0700 (PDT) Received: by milcmima.qntm.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Sep 2000 07:08:38 -0700 Message-ID: <8133266FE373D11190CD00805FA768BF055BD1D6@shrcmsg1.tdh.qntm.com> From: Stephen Byan To: "'Marius Bendiksen'" , Stephen Byan Cc: "'Soren Schmidt'" , fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG Subject: RE: disable write caching with softupdates? Date: Thu, 21 Sep 2000 07:08:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Marius Bendiksen [mailto:mbendiks@eunet.no] wrote: > > Contrast this 10% performance hit versus what you get when=20 > you disable > > caching entirely. >=20 > I think you will see that on some drives, this may have a greater > performance impact than not caching at all. Perhaps S=F8ren will be kind enough to run the experiment? I'd be = interested in analyzing cases in ATA drives where flushing delivers worse = performance than disabling cache. Regards, -Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 7:37:14 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id A827E37B424; Thu, 21 Sep 2000 07:37:09 -0700 (PDT) Received: (from gibbs@localhost) by pluto.plutotech.com (8.9.2/8.9.1) id IAA36298; Thu, 21 Sep 2000 08:35:48 -0600 (MDT) (envelope-from gibbs) From: Justin Gibbs Message-Id: <200009211435.IAA36298@pluto.plutotech.com> Subject: Re: disable write caching with softupdates? In-Reply-To: <8133266FE373D11190CD00805FA768BF055BD1D4@shrcmsg1.tdh.qntm.com> from Stephen Byan at "Sep 21, 2000 6:40:24 am" To: Stephen.Byan@quantum.com (Stephen Byan) Date: Thu, 21 Sep 2000 08:35:48 -0600 (MDT) Cc: mbendiks@eunet.no, Stephen.Byan@quantum.com, fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Without write caching, you pay one disk rotation for each sequential write. This should not be the case if you are allowed to overlap commands. The only penalty should be increased latency in seeing a write complete. Because ATA and now even some SCSI drives only support the "basic queuing" feature set (cannot specify an ordered write barrier to the device), we'll have to find some way to give ordered semantics on these devices or just abandon the use of the B_ORDERED buffer flag. Softupdates does not use it, but FFS does in a few places. Too bad... back when I added it all SCSI devices that supported tagged queuing made this easy to do and I expected to see ATA follow SCSI's lead and implement the same primitive. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 8: 0:12 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 6F4AB37B424; Thu, 21 Sep 2000 08:00:06 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id RAA92422; Thu, 21 Sep 2000 17:02:58 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <200009211502.RAA92422@freebsd.dk> Subject: Re: disable write caching with softupdates? In-Reply-To: <8133266FE373D11190CD00805FA768BF055BD1D6@shrcmsg1.tdh.qntm.com> from Stephen Byan at "Sep 21, 2000 07:08:37 am" To: Stephen.Byan@quantum.com (Stephen Byan) Date: Thu, 21 Sep 2000 17:02:57 +0200 (CEST) Cc: mbendiks@eunet.no ('Marius Bendiksen'), fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It seems Stephen Byan wrote: > Marius Bendiksen [mailto:mbendiks@eunet.no] wrote: > > > > Contrast this 10% performance hit versus what you get when > > you disable > > > caching entirely. > > > > I think you will see that on some drives, this may have a greater > > performance impact than not caching at all. > > Perhaps Søren will be kind enough to run the experiment? I'd be interested > in analyzing cases in ATA drives where flushing delivers worse performance > than disabling cache. Well, I have been toying a bit with this, so far results are just timing of a make -j16 buildworld on two IBM DJNA drives (ie no tags) with varius setups. ATA driver "as is": 3602.63 real 0.00 user 2865.62 sys ATA driver with flush cache on "BIO_ORDERED": 3964.18 real 0.00 user 2870.09 sys ATA driver with write cache disabled: 4423.30 real 0.00 user 2871.87 sys So, having the write cache there definitly is a win. I'll try this on TWO IBM DTLA drives with tags enabled and see what gives.. Anything else you want me to mess with now we are at it ? -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 8:16: 6 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.quantum.com (mx1.quantum.com [204.212.103.34]) by hub.freebsd.org (Postfix) with ESMTP id 750C437B423; Thu, 21 Sep 2000 08:16:01 -0700 (PDT) Received: from milcmima.qntm.com (milcmima.qntm.com [146.174.18.61]) by mx1.quantum.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id IAA06180; Thu, 21 Sep 2000 08:15:52 -0700 (PDT) Received: by milcmima.qntm.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Sep 2000 08:15:50 -0700 Message-ID: <8133266FE373D11190CD00805FA768BF055BD1D7@shrcmsg1.tdh.qntm.com> From: Stephen Byan To: "'Justin Gibbs'" , Stephen Byan Cc: mbendiks@eunet.no, Stephen Byan , fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG Subject: RE: disable write caching with softupdates? Date: Thu, 21 Sep 2000 08:15:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin Gibbs [mailto:gibbs@plutotech.com] wrote: > > Without write caching, you pay one disk rotation for each > sequential write. > > This should not be the case if you are allowed to overlap > commands. The > only penalty should be increased latency in seeing a write complete. You're correct. I was writing with respect to ATA drives, of which I believe only IBM's support write queuing, so I overlooked the case where queuing is available. I'm not that familiar with ATA in practice; the spec for ATA queuing looked sufficiently convoluted (i.e. a kludge) that it wasn't obvious to me that it would be a performance win to implement it. Regards, -Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 8:23:39 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 3DF6F37B424; Thu, 21 Sep 2000 08:23:32 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id RAA98589; Thu, 21 Sep 2000 17:26:17 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <200009211526.RAA98589@freebsd.dk> Subject: Re: disable write caching with softupdates? In-Reply-To: <8133266FE373D11190CD00805FA768BF055BD1D7@shrcmsg1.tdh.qntm.com> from Stephen Byan at "Sep 21, 2000 08:15:50 am" To: Stephen.Byan@quantum.com (Stephen Byan) Date: Thu, 21 Sep 2000 17:26:17 +0200 (CEST) Cc: gibbs@plutotech.com ('Justin Gibbs'), mbendiks@eunet.no, fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It seems Stephen Byan wrote: > Justin Gibbs [mailto:gibbs@plutotech.com] wrote: > > > > Without write caching, you pay one disk rotation for each > > sequential write. > > > > This should not be the case if you are allowed to overlap > > commands. The > > only penalty should be increased latency in seeing a write complete. > > You're correct. I was writing with respect to ATA drives, of which I believe > only IBM's support write queuing, so I overlooked the case where queuing is > available. > > I'm not that familiar with ATA in practice; the spec for ATA queuing looked > sufficiently convoluted (i.e. a kludge) that it wasn't obvious to me that it > would be a performance win to implement it. Well, but it is, I see 5-10% performance gain using tagged queing, so its definitively worth the trouble. I dont think it is that bad, it was easy enough to implement support for in the ATA driver, but so fa I think we are alone in actually using it :) -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 9: 5:38 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 488DF37B422; Thu, 21 Sep 2000 09:05:33 -0700 (PDT) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id SAA25878; Thu, 21 Sep 2000 18:05:31 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id SAA39435; Thu, 21 Sep 2000 18:05:31 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Thu, 21 Sep 2000 18:05:30 +0200 (CEST) From: Marius Bendiksen To: Stephen Byan Cc: fs@FreeBSD.ORG, sos@FreeBSD.ORG, "'freeBSD-scsi@freeBSD.org'" Subject: RE: disable write caching with softupdates? In-Reply-To: <8133266FE373D11190CD00805FA768BF055BD1D4@shrcmsg1.tdh.qntm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Disks are zoned, so there aren't a constant number of sectors per track. Due > to defects, the number of sectors per zone varies from sample to sample. > It's possible that each surface in the drive has a different number of > cylinders. In future disk generations, the geometry may get warped in > unpredictable ways. I agree on this. But I think people would step forth to fix these assumptions in FFS, in time, if disks started reporting real geometry. In either case, I think you would still be likely to get _some_ boost. Layout logic should either be entirely in the FS or entirely in the disk. > Moreover, to take advantage of the geometry, the file system needs an > accurate access time model. The constants in this model may vary from sample > to sample of the same type of drive, and may vary due to environment > conditions like temperature and power supply voltage. (Many of the access > time optimization algorithms in the drives do in fact adapt to these > variations.) The characteristics of the model vary widely between different > designs of drives. Many of these parameters can be adapted to in software, if the firmware will expose the required data. > If you are referring to the SCSI FUA bit, this is absolutely untrue. All > Quantum SCSI drives obey this bit. All currently-manufactured drives obey > this bit. I believe 99% of the drives that claim compliance with the SCSI > SBC spec do in fact obey the FUA bit on writes. There was a recent case > where one manufacturer appears to have cheated and ignored this bit, and > caught quite a bit of abuse for it. Like lost business from major OEMs. Okay. In this case, my information has been incorrect, and I apologize. > Without write caching, you pay one disk rotation for each sequential write. > In workloads with a moderate to high sequential write component, this is an > extreme penalty. Also, with caching enabled, the disk does a fair amount of > reordering to optimize the total seek and rotational cost of the writes. You > give this up when disabling the write cache. I agree that minimizing rotational cost by caching a single track is good, if the drive can guarantee the integrity of the data, possibly by providing an NVRAM buffer for the track. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 9:55: 3 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-115.dsl.snfc21.pacbell.net [63.202.177.115]) by hub.freebsd.org (Postfix) with ESMTP id B35F337B423 for ; Thu, 21 Sep 2000 09:54:31 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id VAA00449; Wed, 20 Sep 2000 21:08:45 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009210408.VAA00449@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Olivier Nicole Cc: freebsd-scsi@freebsd.org Subject: Re: SCSI U160? In-reply-to: Your message of "Thu, 21 Sep 2000 08:27:01 +0700." <200009210127.IAA04342@banyan.cs.ait.ac.th> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Sep 2000 21:08:44 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As I just mentioned on another list, this board has been certified by FreeBSD Labs for FreeBSD 4.1. > --text follows this line-- > Hello, > > Another enquiry, does any of you can confirm that Asus MortherBoard > CUR-DLS ServerWorks ServerSet III LE 3.0, based on ServerSetIII LE > chipset and that includes dual channel U160 is working? > > ServerSetIII LE 3.0 chipset is based on NB6635 NorthBridge 3.0 LE with > 576 Tape Bal Grid Array (TBGA) and IB6566 South Bridge with 352 > Plastic Ball Grid Array (PBGA) [and don't ask me what are TBGA or > PBGA] > > Thank you, > > Olivier > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 10: 9:22 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-115.dsl.snfc21.pacbell.net [63.202.177.115]) by hub.freebsd.org (Postfix) with ESMTP id 05FFF37B423 for ; Thu, 21 Sep 2000 10:09:20 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id KAA00784; Thu, 21 Sep 2000 10:10:06 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009211710.KAA00784@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Marius Bendiksen Cc: freeBSD-scsi@FreeBSD.ORG Subject: Re: disable write caching with softupdates? In-reply-to: Your message of "Thu, 21 Sep 2000 15:38:36 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Sep 2000 10:10:06 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > OK, I played a bit with that, the only info I can see I get from the > > > higher levels is the BIO_ORDERED bit, so I tried to flush the cache > > > each time I get one of those, _bad_ idea, 10% performance loss... > > > That's the price of having a recoverable file system. See Seltzer, Ganger, > > Not necessarily. Er, you're being both contrary and plain wrong. It's a fundamental assumption of the softupdates implementation that it is possible to issue an ordered write and have it complete in an ordered fashion. > > Contrast this 10% performance hit versus what you get when you disable > > caching entirely. > > I think you will see that on some drives, this may have a greater > performance impact than not caching at all. I think that you should perform some objective research on this first. Note that the CAM subsystem already correctly honours BIO_ORDERED by using ordered tags. Also, in another message, you say: > Actually, performance-wise, you'd probably want to know the real geometry, > given all the stuff FFS does to exploit it. Since a) drives don't have 'real' geometries, and haven't for the last half of the last decade at least, and b) we intentionally disable most of these optimisations because they're founded on assumptions that stopped being relevant a good five years before *that*... no, you don't care about the drive's geometry at all. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 10:14:57 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id A6F5F37B423; Thu, 21 Sep 2000 10:14:52 -0700 (PDT) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA09300; Thu, 21 Sep 2000 10:14:52 -0700 Date: Thu, 21 Sep 2000 10:14:47 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Smith Cc: Marius Bendiksen , freeBSD-scsi@FreeBSD.ORG Subject: Re: disable write caching with softupdates? In-Reply-To: <200009211710.KAA00784@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Actually, performance-wise, you'd probably want to know the real geometry, > > given all the stuff FFS does to exploit it. > > Since a) drives don't have 'real' geometries, and haven't for the last > half of the last decade at least, and b) we intentionally disable most of > these optimisations because they're founded on assumptions that stopped > being relevant a good five years before *that*... no, you don't care > about the drive's geometry at all. Actually, drives do most certainly have geoemetries as well as other things which affect performance. It's just that they aren't abstracted enough and the filesystems aren't good enough, to take care of them. And nobody has done that much work to see whether, on the whole, paying attention to them makes sense. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 10:30:38 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 24A2237B422; Thu, 21 Sep 2000 10:30:36 -0700 (PDT) Received: from caspian.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id LAA42240; Thu, 21 Sep 2000 11:30:34 -0600 (MDT) (envelope-from gibbs@plutotech.com) Message-Id: <200009211730.LAA42240@pluto.plutotech.com> To: Mike Smith Cc: scsi@FreeBSD.ORG Subject: Re: disable write caching with softupdates? Date: Thu, 21 Sep 2000 11:31:51 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> > That's the price of having a recoverable file system. See Seltzer, Ganger, >> >> Not necessarily. > > Er, you're being both contrary and plain wrong. It's a fundamental > assumption of the softupdates implementation that it is possible to issue > an ordered write and have it complete in an ordered fashion. Softupdates guarantees write ordering by batching writes that have the same ordering dependency and postponing the writes that depend on queued writes until those writes complete. This is not the same as relying on the ability to queue writes in a particular order. The assumption that softupdates does make, however, is that a write that completes is committed to media. >> Actually, performance-wise, you'd probably want to know the real geometry, >> given all the stuff FFS does to exploit it. > > Since a) drives don't have 'real' geometries, and haven't for the last > half of the last decade at least, and b) we intentionally disable most of > these optimisations because they're founded on assumptions that stopped > being relevant a good five years before *that*... no, you don't care > about the drive's geometry at all. There was a talk (I don't think it was a full blown paper) at a USENIX a few years ago that showed that you could approximate the behavior of modern disks using a liniar model. The speaker also showed some simulated performance improvements by using the model. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 11:33:19 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id EC10C37B440; Thu, 21 Sep 2000 11:33:15 -0700 (PDT) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id UAA61740; Thu, 21 Sep 2000 20:33:14 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id UAA41506; Thu, 21 Sep 2000 20:33:14 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Thu, 21 Sep 2000 20:33:14 +0200 (CEST) From: Marius Bendiksen To: Mike Smith Cc: freeBSD-scsi@FreeBSD.ORG Subject: Re: disable write caching with softupdates? In-Reply-To: <200009211710.KAA00784@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > That's the price of having a recoverable file system. See Seltzer, Ganger, > > Not necessarily. > Er, you're being both contrary and plain wrong. It's a fundamental > assumption of the softupdates implementation that it is possible to issue > an ordered write and have it complete in an ordered fashion. Mike, I was not making the statement that it was not necessary for softupdates and FFS. I was stating that it is possible to design a filesystem in such a fashion that ordering of writes will be less, if any, of a concern. HAS-FS, for example, is not sensitive to the ordering of writes, as I recall. > > I think you will see that on some drives, this may have a greater > > performance impact than not caching at all. > I think that you should perform some objective research on this first. > Note that the CAM subsystem already correctly honours BIO_ORDERED by > using ordered tags. Allow me to point out that I said "I think". I apologize if expressing an assumption, _with_ the necessary qualifier "think", is improper. Do you have any suggestion as to what I may use to indicate something that I think, rather than know, other than saying "think", without making the statement very long? If necessary, I am certainly willing to start using the following wording: I am not certain about this, however, I would assume that on some drives, you may see a greater impact from this than you would by disabling caching. As noted, this is only speculation, though. > > Actually, performance-wise, you'd probably want to know the real geometry, > > given all the stuff FFS does to exploit it. > Since a) drives don't have 'real' geometries, and haven't for the last > half of the last decade at least, Drives have real geometries. The firmware obviously doesn't store things in the ether or anything. However, I have already noted, as have most of the other people in the thread, that these real geometries are often, or always, highly complex, and are therefore masked by the firmware. I hope this elaboration clarifies things. > and b) we intentionally disable most of these optimisations because > they're founded on assumptions that stopped being relevant a good five > years before *that*... no, you don't care about the drive's geometry at > all. Actually, you can do certain optimizations based on the knowledge of how the disk behaves, if you have the ability to use this knowledge in a realtime system. I unfortunately misphrased so as to state that FFS did accurately use this information, which it does not. It would, however, be possible to design a system which exploits this, thus improving performance by, amongst other things, removing rotational latency, and being aware of bad sector remapping, seek timings, zone layout, et al. This would require realtime operation and fine-grained timing, though. There are certainly other things one would benefit from first. And this still relies on having the drive provide the correct information, including such things as temperature, air moisture levels, or whatever. This, as you pointed out, is not reported by disk drives. Again, hope these things clarify. Yours, Marius Bendiksen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 12:31:33 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-115.dsl.snfc21.pacbell.net [63.202.177.115]) by hub.freebsd.org (Postfix) with ESMTP id 3DBD537B443 for ; Thu, 21 Sep 2000 12:31:30 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id MAA01341; Thu, 21 Sep 2000 12:32:22 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009211932.MAA01341@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Marius Bendiksen Cc: freeBSD-scsi@FreeBSD.ORG Subject: Re: disable write caching with softupdates? In-reply-to: Your message of "Thu, 21 Sep 2000 20:33:14 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Sep 2000 12:32:22 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > I think you will see that on some drives, this may have a greater > > > performance impact than not caching at all. > > > I think that you should perform some objective research on this first. > > Note that the CAM subsystem already correctly honours BIO_ORDERED by > > using ordered tags. > > Allow me to point out that I said "I think". I apologize if expressing an > assumption, _with_ the necessary qualifier "think", is improper. Do you > have any suggestion as to what I may use to indicate something that I > think, rather than know, other than saying "think", without making the > statement very long? No. But I said "I think" as well. > > > Actually, performance-wise, you'd probably want to know the real geometry, > > > given all the stuff FFS does to exploit it. > > > Since a) drives don't have 'real' geometries, and haven't for the last > > half of the last decade at least, > > Drives have real geometries. The firmware obviously doesn't store things > in the ether or anything. However, I have already noted, as have most of > the other people in the thread, that these real geometries are often, or > always, highly complex, and are therefore masked by the firmware. > > I hope this elaboration clarifies things. Not really. You link "real" geometries with "all the stuff FFS does to exploit it". FFS' attempts to "exploit" drive geometry are intentionally disabled because they don't work. As was pointed out by another poster, unless you have a good drive access model in the time domain, these optimisations are typically pessimisations anyway. Given that the interaction between code and disk has become significantly further decoupled over the years, and given that many of the parameters of this time domain model are extremely context-sensitive (system performance, controller performance, bus load, disk behaviour), the entire field represents an enormous amount of work for dubious return. In no way does it make sense to allude to the mid-80's style optimisations in FFS and refer to "real" geometries as if there was some trivial way to make everything wonderful again by just getting the "real" geometries right. > And this still relies on having the drive provide the correct information, > including such things as temperature, air moisture levels, or whatever. > This, as you pointed out, is not reported by disk drives. I think ultimately we're in more or less violent agreement. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 12:38: 9 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-115.dsl.snfc21.pacbell.net [63.202.177.115]) by hub.freebsd.org (Postfix) with ESMTP id A247137B43C for ; Thu, 21 Sep 2000 12:38:06 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id MAA01391; Thu, 21 Sep 2000 12:38:52 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009211938.MAA01391@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Justin T. Gibbs" Cc: scsi@FreeBSD.ORG Subject: Re: disable write caching with softupdates? In-reply-to: Your message of "Thu, 21 Sep 2000 11:31:51 MDT." <200009211730.LAA42240@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Sep 2000 12:38:52 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> > That's the price of having a recoverable file system. See Seltzer, Ganger, > >> > >> Not necessarily. > > > > Er, you're being both contrary and plain wrong. It's a fundamental > > assumption of the softupdates implementation that it is possible to issue > > an ordered write and have it complete in an ordered fashion. > > Softupdates guarantees write ordering by batching writes that have the > same ordering dependency and postponing the writes that depend on queued > writes until those writes complete. This is not the same as relying on > the ability to queue writes in a particular order. The assumption that > softupdates does make, however, is that a write that completes is committed > to media. That's correct, and it's an implementation bug, albeit one that is difficult to work around. (Consider the case where you have a storage device that reorders requests, has a large buffer and performs write-back caching.) I tend to concur with Kirk's opinion that if you want to perform this sort of decoupling, either you make it nonvolatile or you accept that shooting between your feet gives you a nonzero chance of taking off a toe every now and then. 8) > >> Actually, performance-wise, you'd probably want to know the real geometry, > >> given all the stuff FFS does to exploit it. > > > > Since a) drives don't have 'real' geometries, and haven't for the last > > half of the last decade at least, and b) we intentionally disable most of > > these optimisations because they're founded on assumptions that stopped > > being relevant a good five years before *that*... no, you don't care > > about the drive's geometry at all. > > There was a talk (I don't think it was a full blown paper) at a USENIX > a few years ago that showed that you could approximate the behavior > of modern disks using a liniar model. The speaker also showed some > simulated performance improvements by using the model. Can I assume you mean "linear" here, ie. that you can model a disk's performance based on a more or less linear progression from "slow" at one extreme to "fast" at the other? (I can see how some of the fixed delays eg. settling time, rotational latency, etc. factor out, so this makes sense.) Thanks. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 13:35:36 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id EE5A537B446; Thu, 21 Sep 2000 13:35:28 -0700 (PDT) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id NAA18138; Thu, 21 Sep 2000 13:35:42 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAAh.aaJG; Thu Sep 21 13:33:11 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id NAA15839; Thu, 21 Sep 2000 13:32:42 -0700 (MST) From: Terry Lambert Message-Id: <200009212032.NAA15839@usr08.primenet.com> Subject: Re: disable write caching with softupdates? To: mbendiks@eunet.no (Marius Bendiksen) Date: Thu, 21 Sep 2000 20:32:41 +0000 (GMT) Cc: Stephen.Byan@quantum.com (Stephen Byan), sos@freebsd.dk ('Soren Schmidt'), fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG In-Reply-To: from "Marius Bendiksen" at Sep 21, 2000 03:38:36 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > OK, I played a bit with that, the only info I can see I get from the > > > higher levels is the BIO_ORDERED bit, so I tried to flush the cache > > > each time I get one of those, _bad_ idea, 10% performance loss... > > > That's the price of having a recoverable file system. See Seltzer, Ganger, > > Not necessarily. > > > Contrast this 10% performance hit versus what you get when you disable > > caching entirely. > > I think you will see that on some drives, this may have a greater > performance impact than not caching at all. There will always be a performance impact, since this will, of necessity, stall the write pipeline for the synchronization, unless there are a lot of graphically unrelated I/O's pending. At least in this way, soft updates is better than delayed ordered writes (DOW -- patented by USL, and used without permission in ReiserFS), in that DOW will stall all I/O when hitting a synchronization point, whereas SU will only stall dependent I/O. That said, the question is whether the drive will flush the cache and mark it invalid, or will merely flush the cache to disk, and leave the cache contents intact. If it does the former, then there could be additional overhead for subsequent reads. Really, the OS needs to know the cache strategy of the drive, and follow the same strategy itself, to reduce the number of drive to OS transactions, and to remove the problem of the drive having to go back to the well for a subsequent read, if the cache contents are effectively discarded. Frankly, I find it hard to believe that a cache flush would result in other than a mere write, e.g. that any drive would be so dumb as to discard. But there might be other consequences, since the cache on the drive may all get marked clean, which would result in a natural disordering of the reuse of cache buffers. This may be more or less optimal: it depends on usage patterns by the OS. So minimally, some experimentation should be done with the drive and OS in terms of the OS using mode page 2 to obtain the drive geometry for variable geometry drives, and apply the standard seek optimizations that are currently disabled in FFS, as well as placing the OS caching on a track granularity to match the cache characteristics on most modern drives. --- On a semi-related note, I have done some experimentation with some (admittedly older) code that gave ownership of the vnode to the FS, per SunOS and USL approaches, e.g., instead of two separate allocations: ,-------. <-. ,-->,-------. | inode | | | | vnode | | | | | | | | | `-----------| | | |-----------' | | | | | | `-------' `-------' Having a single allocation: ,-------.<---. | vnode | | | | | | |--. | | | | | |-------|<-' | | inode | | | | | | |----' | | `-------' Which avoids the ability of the vclean() to disassociate valid cached data from ihash objects by reclaiming the vnode out from under the inode, without the inode also being reclaimed, making the operation idempotent in both directions, and then totally removing the ihash(), since the vnode is allocated as part of allocating the in core inode (this avoids the SVR3 inode size limitation problem, which the Berkeley people resolved via a divorce). I measured a better than 30% performance increase on heavily loaded systems by doing this (this was 3.2 code, so take that for what it's worth, which is, I think, a lot, since things have not changed _that_ much). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 13:44: 8 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 870F437B440; Thu, 21 Sep 2000 13:44:04 -0700 (PDT) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id NAA22534; Thu, 21 Sep 2000 13:44:20 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAAtuaW8R; Thu Sep 21 13:44:11 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id NAA16157; Thu, 21 Sep 2000 13:43:52 -0700 (MST) From: Terry Lambert Message-Id: <200009212043.NAA16157@usr08.primenet.com> Subject: Re: disable write caching with softupdates? To: sos@freebsd.dk (Soren Schmidt) Date: Thu, 21 Sep 2000 20:43:49 +0000 (GMT) Cc: Stephen.Byan@quantum.com (Stephen Byan), mbendiks@eunet.no ('Marius Bendiksen'), fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG In-Reply-To: <200009211502.RAA92422@freebsd.dk> from "Soren Schmidt" at Sep 21, 2000 05:02:57 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > ATA driver with flush cache on "BIO_ORDERED": > 3964.18 real 0.00 user 2870.09 sys > > ATA driver with write cache disabled: > 4423.30 real 0.00 user 2871.87 sys > > So, having the write cache there definitly is a win. > > I'll try this on TWO IBM DTLA drives with tags enabled and see what gives.. > > Anything else you want me to mess with now we are at it ? I suspect that much of this difference is unnecessary I/O bus transactions to recover "lost" cached data resulting from the inode/vnode disassociation. Try significantly increasing the number of vnodes in your system, and the ihash pool size, and see if it has any effect on the second set of numbers, by reducing the bus overhead through unnecessary reclaims. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 13:47:41 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1AFD737B423; Thu, 21 Sep 2000 13:47:37 -0700 (PDT) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA09886; Thu, 21 Sep 2000 13:41:02 -0700 Date: Thu, 21 Sep 2000 13:37:46 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Terry Lambert Cc: Marius Bendiksen , Stephen Byan , "'Soren Schmidt'" , fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG Subject: Re: disable write caching with softupdates? In-Reply-To: <200009212032.NAA15839@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Really, the OS needs to know the cache strategy of the drive, and > follow the same strategy itself, to reduce the number of drive to > OS transactions, and to remove the problem of the drive having to > go back to the well for a subsequent read, if the cache contents > are effectively discarded. It's simple enough- at least with SCSI. If you enable write cacheing, you should then allow for the filesystem to issue an ioctl that can use the SYNCHRONIZE CACHE command to provide the commit point. There are also flavors of readns and writes that can affect cache retention policies for certain blocks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 13:50:44 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.quantum.com (mx1.quantum.com [204.212.103.34]) by hub.freebsd.org (Postfix) with ESMTP id 83DC337B424; Thu, 21 Sep 2000 13:50:40 -0700 (PDT) Received: from milcmima.qntm.com (milcmima.qntm.com [146.174.18.61]) by mx1.quantum.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id NAA08676; Thu, 21 Sep 2000 13:50:35 -0700 (PDT) Received: by milcmima.qntm.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Sep 2000 13:50:34 -0700 Message-ID: <8133266FE373D11190CD00805FA768BF055BD1DB@shrcmsg1.tdh.qntm.com> From: Stephen Byan To: "'Marius Bendiksen'" , Mike Smith Cc: freeBSD-scsi@FreeBSD.ORG, "'fs@freeBSD.org'" Subject: RE: disable write caching with softupdates? Date: Thu, 21 Sep 2000 13:39:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Marius Bendiksen [mailto:mbendiks@eunet.no] wrote: > Actually, you can do certain optimizations based on the > knowledge of how > the disk behaves, if you have the ability to use this knowledge in a > realtime system. I unfortunately misphrased so as to state > that FFS did > accurately use this information, which it does not. It would, however, > be possible to design a system which exploits this, thus improving > performance by, amongst other things, removing rotational latency, and > being aware of bad sector remapping, seek timings, zone layout, et al. > This would require realtime operation and fine-grained timing, though. > There are certainly other things one would benefit from first. > > And this still relies on having the drive provide the correct > information, > including such things as temperature, air moisture levels, or > whatever. > This, as you pointed out, is not reported by disk drives. I think this is one of the more interesting things about the NASD and object-based disk proposals. Since they push the file-store layer down to the disk, the block allocation policy can take all of these things into account, without having to specify an intermediate abstraction layer to convey the necessary information, since the form of that information changes frequently as a reflection of the volatility of the underlying technology in the disk drive. Regards, -Steve Steve Byan Design Engineer MS 1-3/E23 333 South Street Shrewsbury, MA 01545 (508)770-3414 fax: (508)770-2604 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 13:50:49 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id E131737B42C; Thu, 21 Sep 2000 13:50:41 -0700 (PDT) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id NAA14670; Thu, 21 Sep 2000 13:49:16 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAA04aayC; Thu Sep 21 13:49:00 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id NAA16305; Thu, 21 Sep 2000 13:50:21 -0700 (MST) From: Terry Lambert Message-Id: <200009212050.NAA16305@usr08.primenet.com> Subject: Re: disable write caching with softupdates? To: mbendiks@eunet.no (Marius Bendiksen) Date: Thu, 21 Sep 2000 20:50:21 +0000 (GMT) Cc: Stephen.Byan@quantum.com (Stephen Byan), fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG ('freeBSD-scsi@freeBSD.org') In-Reply-To: from "Marius Bendiksen" at Sep 21, 2000 06:05:30 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Disks are zoned, so there aren't a constant number of sectors per track. Due > > to defects, the number of sectors per zone varies from sample to sample. > > It's possible that each surface in the drive has a different number of > > cylinders. In future disk generations, the geometry may get warped in > > unpredictable ways. > > I agree on this. But I think people would step forth to fix these > assumptions in FFS, in time, if disks started reporting real geometry. > In either case, I think you would still be likely to get _some_ boost. > Layout logic should either be entirely in the FS or entirely in the disk. This is avaialble in the SCSI 2 standard, on all conforming drives. > I agree that minimizing rotational cost by caching a single track is good, > if the drive can guarantee the integrity of the data, possibly by > providing an NVRAM buffer for the track. Most modern disks will always track-cache, since they write sectors in reverse order. For read operations, immediately following a seek, they start reading into cache at wherever the head is on the disk, and buffer that until they hit the requested data. The result is that sequential data is already loaded into the cache by the time that the next read goes to the drive. Right about now, someone should nudge Rod Grimes to get into this discussion, since he has played with some of this type of disk optimization. Now that it's under a microscope again, it might also be time to consider his spindle-sync work, as well as other stuff that's more hardware dependent. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 13:52:23 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id C526F37B424; Thu, 21 Sep 2000 13:52:17 -0700 (PDT) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id NAA18515; Thu, 21 Sep 2000 13:37:41 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAAubaWBI; Thu Sep 21 13:36:19 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id NAA15997; Thu, 21 Sep 2000 13:38:37 -0700 (MST) From: Terry Lambert Message-Id: <200009212038.NAA15997@usr08.primenet.com> Subject: Re: disable write caching with softupdates? To: Stephen.Byan@quantum.com (Stephen Byan) Date: Thu, 21 Sep 2000 20:38:37 +0000 (GMT) Cc: mbendiks@eunet.no ('Marius Bendiksen'), Stephen.Byan@quantum.com (Stephen Byan), fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG ('freeBSD-scsi@freeBSD.org') In-Reply-To: <8133266FE373D11190CD00805FA768BF055BD1D4@shrcmsg1.tdh.qntm.com> from "Stephen Byan" at Sep 21, 2000 06:40:24 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The problem with exposing the disk geometry is that FFS makes assumptions > about the geometry that are false. FFS is wrong, here. > Disks are zoned, so there aren't a constant number of sectors per track. Due > to defects, the number of sectors per zone varies from sample to sample. > It's possible that each surface in the drive has a different number of > cylinders. In future disk generations, the geometry may get warped in > unpredictable ways. Mode page 2. Yes, this will leave IDE drives out in the cold, but let them grow a mode page 2, or suffer the consequences. > Moreover, to take advantage of the geometry, the file system needs an > accurate access time model. The constants in this model may vary from sample > to sample of the same type of drive, and may vary due to environment > conditions like temperature and power supply voltage. (Many of the access > time optimization algorithms in the drives do in fact adapt to these > variations.) The characteristics of the model vary widely between different > designs of drives. Mostly, all it needs to know whether rotational latency is significantly lower than seek latency, which it is. > So it's hard to envision a standard way of expressing the actual drive > geometry and access time model to the file system. You don't need to be accurate, as much as you need to be correct, and in the ballpark on rotational vs. seek latencies. > > As I recall, and from what Eivind noted, this bit is > > routinely ignored in > > about 90% of all drives out there. > > If you are referring to the SCSI FUA bit, this is absolutely untrue. All > Quantum SCSI drives obey this bit. All currently-manufactured drives obey > this bit. I believe 99% of the drives that claim compliance with the SCSI > SBC spec do in fact obey the FUA bit on writes. There was a recent case > where one manufacturer appears to have cheated and ignored this bit, and > caught quite a bit of abuse for it. Like lost business from major OEMs. > > If you are referring to the flush cache command for ATA drives, you may have > a point. For ATA drives, earlier versions of the ATA spec did not specify a > way to flush the cache. The ATA driver in Windows NT appears to have > implemented one vendor's vendor-unique command to flush the cache, which is > not widely-supported and which has been superceded by a standard "flush > cache" command in the newer versions of the ATA specification. These guys were talking about ATA drives, which ignore the bit. Most SCSI drives, as you point out, do not. And this is a heck of a lot better approach than flushing the cache via an explicit instruction. The SCSI stuff can be handled with a "known rogues" list, but the ATA stuff is pretty much unhandleable at this point. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 21 14:45:58 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from troi.csw.net (troi.csw.net [209.136.192.23]) by hub.freebsd.org (Postfix) with ESMTP id A252837B43E for ; Thu, 21 Sep 2000 14:45:55 -0700 (PDT) Received: from ssaos2 (ssaos2.csw.net [209.136.201.13]) by troi.csw.net (8.9.3/8.9.3) with SMTP id QAA26390 for ; Thu, 21 Sep 2000 16:45:42 -0500 (CDT) (envelope-from lambert@cswnet.com) Message-Id: <200009212145.QAA26390@troi.csw.net> From: lambert@cswnet.com Date: Thu, 21 Sep 2000 16:45:39 -0400 To: freebsd-scsi@freebsd.org In-Reply-To: <20000921145118.J215@netcraft.com> Subject: Re: sys/dev/aic7xxx MFC X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.10a c10 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In <20000921145118.J215@netcraft.com>, on 09/21/2000 at 02:51 PM, Jonathan Perkin said: >Hey guys. >Recently there have been quite a few reports of breakage with 29160/7892 >ahc and Supermicro combinations, of which most are fixed in -current. >For those of us running -stable, is there likelyhood of an MFC soon >(preferably before the 4.1.1 point release), or does anyone have homebrew >patches to fix the reported problems? >(For reference, the system is Supermicro 370DLE Dual 667MHz P3, Adaptec >7892 on-board, and Seagate ST39236LW/ST173404LW drives - showing the SCB >resets/QUOTPOS errors which render a 4.1-R install impossible) I have this board and got things to work by changing the jumper for the 64-bit PCI bus speed to 33Mhz instead of 66Mhz. It has survived two 'make -j 32 buildworld' runs. One without softupdates, the other with softupdates. At 66Mhz the machine doesn't survive a CVSup. We did install on another motherboard with built-in Adaptec 2940UW. I was on vacation while they did the install so I don't know if changing the bus speed would have allowed them to install on the Supermicro board. -- Scott Lambert lambert@cswnet.com Systems and Security Administrator CSW Net, Inc. ================================================================ Written: Thursday, September 21, 2000 - 12:23 PM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Sep 22 1: 0:43 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from netplex.com.au (adsl-63-207-30-186.dsl.snfc21.pacbell.net [63.207.30.186]) by hub.freebsd.org (Postfix) with ESMTP id 6312737B422; Fri, 22 Sep 2000 01:00:38 -0700 (PDT) Received: from netplex.com.au (peter@localhost [127.0.0.1]) by netplex.com.au (8.11.0/8.9.3) with ESMTP id e8M7vtG46023; Fri, 22 Sep 2000 00:57:55 -0700 (PDT) (envelope-from peter@netplex.com.au) Message-Id: <200009220757.e8M7vtG46023@netplex.com.au> X-Mailer: exmh version 2.1.1 10/15/1999 To: Soren Schmidt Cc: Stephen.Byan@quantum.com (Stephen Byan), mbendiks@eunet.no ('Marius Bendiksen'), fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG Subject: Re: disable write caching with softupdates? In-Reply-To: <200009211502.RAA92422@freebsd.dk> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Fri, 22 Sep 2000 00:57:55 -0700 From: Peter Wemm Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Soren Schmidt wrote: > It seems Stephen Byan wrote: > > Marius Bendiksen [mailto:mbendiks@eunet.no] wrote: > > > > > > Contrast this 10% performance hit versus what you get when > > > you disable > > > > caching entirely. > > > > > > I think you will see that on some drives, this may have a greater > > > performance impact than not caching at all. > > > > Perhaps Søren will be kind enough to run the experiment? I'd be interested > > in analyzing cases in ATA drives where flushing delivers worse performance > > than disabling cache. > > Well, I have been toying a bit with this, so far results are just > timing of a make -j16 buildworld on two IBM DJNA drives (ie no tags) > with varius setups. > > ATA driver "as is": > 3602.63 real 0.00 user 2865.62 sys > > ATA driver with flush cache on "BIO_ORDERED": > 3964.18 real 0.00 user 2870.09 sys > > ATA driver with write cache disabled: > 4423.30 real 0.00 user 2871.87 sys > > So, having the write cache there definitly is a win. It is a win only if you do not value your data. I would gladly turn it off. How do we do this right now? (ie: completely off) > I'll try this on TWO IBM DTLA drives with tags enabled and see what gives.. I'm curious to know if tagged queueing compensates for the loss incurred by disabling write caching. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Sep 22 1:10:29 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id B5F0F37B423; Fri, 22 Sep 2000 01:10:24 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id KAA38726; Fri, 22 Sep 2000 10:13:13 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <200009220813.KAA38726@freebsd.dk> Subject: Re: disable write caching with softupdates? In-Reply-To: <200009220757.e8M7vtG46023@netplex.com.au> from Peter Wemm at "Sep 22, 2000 00:57:55 am" To: peter@netplex.com.au (Peter Wemm) Date: Fri, 22 Sep 2000 10:13:13 +0200 (CEST) Cc: Stephen.Byan@quantum.com (Stephen Byan), mbendiks@eunet.no ('Marius Bendiksen'), fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It seems Peter Wemm wrote: > > Well, I have been toying a bit with this, so far results are just > > timing of a make -j16 buildworld on two IBM DJNA drives (ie no tags) > > with varius setups. > > > > ATA driver "as is": > > 3602.63 real 0.00 user 2865.62 sys > > > > ATA driver with flush cache on "BIO_ORDERED": > > 3964.18 real 0.00 user 2870.09 sys > > > > ATA driver with write cache disabled: > > 4423.30 real 0.00 user 2871.87 sys > > > > So, having the write cache there definitly is a win. > > It is a win only if you do not value your data. I would gladly turn it off. > How do we do this right now? (ie: completely off) Se the patch from yesterday, but I'llcome up with a better one (sysctl) as soon as I get a few hours... > > I'll try this on TWO IBM DTLA drives with tags enabled and see what gives.. > > I'm curious to know if tagged queueing compensates for the loss incurred by > disabling write caching. I'll know later today and will post my findings... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Sep 22 1:32:18 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id B16DC37B42C; Fri, 22 Sep 2000 01:32:13 -0700 (PDT) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id BAA23297; Fri, 22 Sep 2000 01:32:30 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAmJaGDT; Fri Sep 22 01:32:24 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id BAA09658; Fri, 22 Sep 2000 01:32:02 -0700 (MST) From: Terry Lambert Message-Id: <200009220832.BAA09658@usr05.primenet.com> Subject: Re: disable write caching with softupdates? To: peter@netplex.com.au (Peter Wemm) Date: Fri, 22 Sep 2000 08:32:02 +0000 (GMT) Cc: sos@freebsd.dk (Soren Schmidt), Stephen.Byan@quantum.com (Stephen Byan), mbendiks@eunet.no ('Marius Bendiksen'), fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG In-Reply-To: <200009220757.e8M7vtG46023@netplex.com.au> from "Peter Wemm" at Sep 22, 2000 12:57:55 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > So, having the write cache there definitly is a win. > > It is a win only if you do not value your data. I would gladly turn it off. > How do we do this right now? (ie: completely off) > > > I'll try this on TWO IBM DTLA drives with tags enabled and see what gives.. > > I'm curious to know if tagged queueing compensates for the loss incurred by > disabling write caching. For a multiple application system, the anser is "yes", so long as there are enough applications that the average stall time for a context switch equals or exceeds the latency induced by waiting for the write to complete (standard queueing theory 8-)). For a single user workstation, where there is generall only one or two applications running, the answer would be "no". For you to be able to see this, the appropriate test is probably a "make world" (or a similar large multielement compile) with an argument between "-j 8" and -j 12". Note that you should probably _not_ use a memfs /tmp for this, at the same time, since what you want to stress is the impact on concurrency under a multiprogram load. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Sep 22 7:18:10 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 1ECBD37B423; Fri, 22 Sep 2000 07:18:07 -0700 (PDT) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id QAA17256; Fri, 22 Sep 2000 16:18:06 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id QAA48955; Fri, 22 Sep 2000 16:18:05 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Fri, 22 Sep 2000 16:18:05 +0200 (CEST) From: Marius Bendiksen To: Mike Smith Cc: freeBSD-scsi@FreeBSD.ORG Subject: Re: disable write caching with softupdates? In-Reply-To: <200009211932.MAA01341@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Not really. You link "real" geometries with "all the stuff FFS does to > exploit it". FFS' attempts to "exploit" drive geometry are intentionally > disabled because they don't work. As was pointed out by another poster, > unless you have a good drive access model in the time domain, these > optimisations are typically pessimisations anyway. This fault was ceded in a later post, as I recall. FFS currently does not handle sufficiently complex geometric parameters that exposing the real ones would make an improvement. I do think it likely that someone would step forth and implement this properly, though, if an interface should become available to obtain such information, and, if we had realtime ability with fine grained timing. > > And this still relies on having the drive provide the correct information, > > including such things as temperature, air moisture levels, or whatever. > > This, as you pointed out, is not reported by disk drives. > > I think ultimately we're in more or less violent agreement. 8) Highly likely. Let's not get further into this. I will, and have, ceded the point that there are other optimizations that take precedence over the geometric ones. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Sep 22 8:51:13 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from Gloria.CAM.ORG (Gloria.CAM.ORG [205.151.116.34]) by hub.freebsd.org (Postfix) with ESMTP id CB20337B422; Fri, 22 Sep 2000 08:51:10 -0700 (PDT) Received: from localhost (intmktg@localhost) by Gloria.CAM.ORG (8.9.3/8.9.3) with ESMTP id LAA32027; Fri, 22 Sep 2000 11:54:10 -0400 Date: Fri, 22 Sep 2000 11:54:10 -0400 (EDT) From: Marc Tardif To: freebsd-fs@freebsd.org, freebsd-scsi@freebsd.org Subject: ccd with other filesystems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At which level does ccd concatenate or mirror disks? Is the operation performed on slices or partitions? If slices, does it have to be set to sysid 165? If partitions, does it have to be in the FFS format? I ask because I'm not sure how the word "partition" is used in the manpage, is it suppose to mean a slice (as in DOS partition) or the partition of a slice? Also, I'm intrigued by the following passage: Note that the `raw' partitions of the disks should not be combined. The kernel will only allow component partitions of type FS_BSDFFS. Does this mean ccd will only accept FFS partitions? Could msdos partitions, be concatenated or mirrored for example? Also, why does it say "the keryenl will only allow", isn't it ccd which allows? Lastly, if ccd doesn't act on raw partitions, does that apply to vinum also? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Sep 22 15: 6: 4 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 4BB6B37B422; Fri, 22 Sep 2000 15:06:00 -0700 (PDT) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e8MM5uI27728 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sat, 23 Sep 2000 00:05:58 +0200 (MET DST) Received: from cicely5.cicely.de (cicely5.cicely.de [fec0::104:200:92ff:fe9b:20e7]) by mail.cicely.de (8.11.0.Beta1/8.11.0.Beta1) with ESMTP id e8MM6AT12984; Sat, 23 Sep 2000 00:06:11 +0200 (CEST) Received: (from ticso@localhost) by cicely5.cicely.de (8.11.0/8.9.2) id e8MM66K00557; Sat, 23 Sep 2000 00:06:06 +0200 (CEST) (envelope-from ticso) Date: Sat, 23 Sep 2000 00:06:05 +0200 From: Bernd Walter To: Mike Smith Cc: Marius Bendiksen , freeBSD-scsi@freebsd.org Subject: Re: disable write caching with softupdates? Message-ID: <20000923000605.A448@cicely5.cicely.de> References: <200009211710.KAA00784@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200009211710.KAA00784@mass.osd.bsdi.com>; from msmith@freebsd.org on Thu, Sep 21, 2000 at 10:10:06AM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Sep 21, 2000 at 10:10:06AM -0700, Mike Smith wrote: > > > > OK, I played a bit with that, the only info I can see I get from the > > > > higher levels is the BIO_ORDERED bit, so I tried to flush the cache > > > > each time I get one of those, _bad_ idea, 10% performance loss... > > > > > That's the price of having a recoverable file system. See Seltzer, Ganger, > > > > Not necessarily. > > Er, you're being both contrary and plain wrong. It's a fundamental > assumption of the softupdates implementation that it is possible to issue > an ordered write and have it complete in an ordered fashion. Now I'm very confused ;( That's what Matthew Dillon wrote on -current in May: : Wait a sec... softupdates does not depend on write ordering. Softupdates : issues all non-conflicting writes in parallel and doesn't care what order : they are written to the disk. When those complete, softupdates will then : followup with all the writes that depend on the original set. As far as I know Kirk McKusick had bad expiriences with disks not honouring the ordered stuff. What is the truth? -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Sep 22 15:11:39 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-89-203.dsl.snfc21.pacbell.net [63.206.89.203]) by hub.freebsd.org (Postfix) with ESMTP id 3F71F37B43E for ; Fri, 22 Sep 2000 15:11:29 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8MMCKA00399; Fri, 22 Sep 2000 15:12:20 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009222212.e8MMCKA00399@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Bernd Walter Cc: Marius Bendiksen , freeBSD-scsi@freebsd.org Subject: Re: disable write caching with softupdates? In-reply-to: Your message of "Sat, 23 Sep 2000 00:06:05 +0200." <20000923000605.A448@cicely5.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Sep 2000 15:12:20 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Thu, Sep 21, 2000 at 10:10:06AM -0700, Mike Smith wrote: > > > > > OK, I played a bit with that, the only info I can see I get from the > > > > > higher levels is the BIO_ORDERED bit, so I tried to flush the cache > > > > > each time I get one of those, _bad_ idea, 10% performance loss... > > > > > > > That's the price of having a recoverable file system. See Seltzer, Ganger, > > > > > > Not necessarily. > > > > Er, you're being both contrary and plain wrong. It's a fundamental > > assumption of the softupdates implementation that it is possible to issue > > an ordered write and have it complete in an ordered fashion. > > Now I'm very confused ;( > > That's what Matthew Dillon wrote on -current in May: > > : Wait a sec... softupdates does not depend on write ordering. Softupdates > : issues all non-conflicting writes in parallel and doesn't care what order > : they are written to the disk. When those complete, softupdates will then > : followup with all the writes that depend on the original set. > > As far as I know Kirk McKusick had bad expiriences with disks not > honouring the ordered stuff. > > What is the truth? I stated it poorly. Softupdates does depend on the equivalent of "write barrier" semantics, as Matt describes. It doesn't explicitly issue "ordered" writes because it's running lots of separately dependant write chains in parallel, while a true "barrier" would apply across all writes. The semantic that softupdates desires is difficult to achieve. It can be best approximated using a disk controller with nonvolatile cache memory (as this reduces some of the windows to nearly zero). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Sep 22 21: 8:26 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id D3C1C37B423; Fri, 22 Sep 2000 21:08:16 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e8N486S89558; Sat, 23 Sep 2000 13:38:06 +0930 (CST) (envelope-from grog) Date: Sat, 23 Sep 2000 13:38:06 +0930 From: Greg Lehey To: Marc Tardif Cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: ccd with other filesystems Message-ID: <20000923133806.B78943@wantadilla.lemis.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from intmktg@CAM.ORG on Fri, Sep 22, 2000 at 11:54:10AM -0400 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Friday, 22 September 2000 at 11:54:10 -0400, Marc Tardif wrote: > At which level does ccd concatenate or mirror disks? Is the > operation performed on slices or partitions? Partitions. > If slices, does it have to be set to sysid 165? If partitions, does > it have to be in the FFS format? ccd requires a ufs partition (4.2BSD in the disk label). This is stupid, since what it puts there is not a ufs file system, and it encourages you to shoot yourself in the foot and overwrite a ufs file system. > I ask because I'm not sure how the word "partition" is used > in the manpage, is it suppose to mean a slice (as in DOS > partition) or the partition of a slice? Also, I'm intrigued > by the following passage: > Note that the `raw' partitions of the disks should not be > combined. I really don't understand what this is supposed to mean. > The kernel will only allow component partitions of type FS_BSDFFS. This is basically saying the same thing as I said above: you need a partition of 4.2BSD. > Does this mean ccd will only accept FFS partitions? Yes. > Could msdos partitions, be concatenated or mirrored for example? Don't confuse the partition type that ccd wants with the data you put on it. You can put MS-DOS file systems on ccd, though I can't imagine why you'd want to. > Also, why does it say "the keryenl will only allow", isn't it ccd > which allows? Yes. But it's in the kernel. > Lastly, if ccd doesn't act on raw partitions, does that apply to > vinum also? Vinum requires partitions of type (wait for it) Vinum. We now only have raw partitions, so both work with them. But a raw partition isn't the same thing as a non-4.2BSD partition. On the whole, I'd recommend using Vinum, which is more actively maintained and gives you more flexibility. But I suspect you still have a question out there which I haven't been able to guess. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Sep 23 6:58:48 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from cs4.cs.ait.ac.th (cs4.cs.ait.ac.th [192.41.170.15]) by hub.freebsd.org (Postfix) with ESMTP id CD27A37B424; Sat, 23 Sep 2000 06:58:42 -0700 (PDT) Received: from bazooka.cs.ait.ac.th (on@bazooka.cs.ait.ac.th [192.41.170.2]) by cs4.cs.ait.ac.th (8.9.3/8.9.3) with ESMTP id IAA16331; Sat, 23 Sep 2000 08:25:22 +0700 (GMT+0700) From: Olivier Nicole Received: (from on@localhost) by bazooka.cs.ait.ac.th (8.8.5/8.8.5) id IAA05688; Sat, 23 Sep 2000 08:25:21 +0700 (ICT) Date: Sat, 23 Sep 2000 08:25:21 +0700 (ICT) Message-Id: <200009230125.IAA05688@bazooka.cs.ait.ac.th> To: intmktg@CAM.ORG Cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-reply-to: (message from Marc Tardif on Fri, 22 Sep 2000 11:54:10 -0400 (EDT)) Subject: Re: ccd with other filesystems Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As far as I know (FreeBSD 2.2.7, yes!) at partition level (Unix partition) Well I used one partition per slice anyway. Olivier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message