From owner-cvs-all Tue Jan 19 23:50:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA19883 for cvs-all-outgoing; Tue, 19 Jan 1999 23:50:12 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from feral-gw.feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA19877; Tue, 19 Jan 1999 23:50:10 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral-gw.feral.com (8.8.7/8.8.7) with ESMTP id XAA23045; Tue, 19 Jan 1999 23:49:43 -0800 Date: Tue, 19 Jan 1999 23:49:43 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Matthew Dillon cc: "Kenneth D. Merry" , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_xpt.c In-Reply-To: <199901200731.XAA00578@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk y > :Yes, that's true. Sorry- I wasn't thinking clearly. It is just that > :retrofitting for breakage is a losing game. > : > :It might make more sense to limit tags to something lower *unless* there's > :a quirks that says this drive can take a lot. By and large I'd really > :wonder that > 8 per spindle makes any sense at all. > : > > Oh yah, it definitely makes sense. I dunno about reversing the state > of the quirk, but there are major performance benefits to being able > to queue a large number of commands to a drive on a heavily loaded > system. > > Not only that, but a SCSI unit might not address just a single HD. A > RADI SCSI unit, for example, might fan-out to many drives and limiting > the tags to 8 would have a severe effect on performance. > The latter I'd believe. The former I question. I seriously doubt that a lot of drives have the moxie to effectively do a generation based staggered elevator the correctly balances performance with latency. In general I approve of the way it's currently set up. Adding tags after the fact for devices we find broken is just ridiculous. Perhaps if we had a way to store persistent errors (it depends whether the 'freeze' can be resolved with a BDR or a bus reset). This is a tough judgement call- and really needs a hint as to what people expect from their system. If this were a system for the average user, I'd err on the side of caution (lower performance). If this were a system where performance was to be maximized, I'd go for the gusto. Can we get a config hint on this? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message