Date: Tue, 19 Jan 1999 23:49:43 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: "Kenneth D. Merry" <ken@plutotech.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_xpt.c Message-ID: <Pine.LNX.4.04.9901192345350.22998-100000@feral-gw> In-Reply-To: <199901200731.XAA00578@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.04.9901192345350.22998-100000>