Date: Sun, 15 Mar 1998 05:55:21 -0600 From: Karl Denninger <karl@mcs.net> To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> Cc: scsi@FreeBSD.ORG Subject: Re: CAM question Message-ID: <19980315055521.51883@mcs.net> In-Reply-To: <199803150546.WAA04774@narnia.plutotech.com>; from Justin T. Gibbs on Sat, Mar 14, 1998 at 10:46:23PM -0700 References: <19980314122132.45239@mcs.net> <199803150546.WAA04774@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 14, 1998 at 10:46:23PM -0700, Justin T. Gibbs wrote: > > The big problem with things like systat is that it completely breaks them > > (not just returning no data, but causing them to blow up entirely). > > Seems to work just fine on my CAM systems (other than not returning > and disk data and telling you nicely that "-iostat" makes little > sense for a system that reports having no drives). I don't believe > that we've changed anything in the systat code for CAM (yet) and > if systat blows up when there are no drives in the system (dkndrive > is 0), then systat was broken long before CAM came around (think > diskless configurations). For the short term, I'm more concerned > with implementing full SCSI controller and device support than > fixing things like systat, so if you feel that "not having systat" > is too much of a restriction to using CAM, you're more than welcome > not to use the patches. > > -- > Justin Hmmm... I'll take a look at the systat code; I get a complaint about dk_ndrive = 0 and the "vmstat" display refuses to come up. "pigs" works ok, but that's not where I usually spend my time on that display :-) I don't really care about the I/O statistics - I can use IOSTAT for that, and that does work (very nicely in fact). The "vmstat" display is very useful for figuring out how badly you're thrashing namei caches and such, as well as getting a handle on interrupt rates and general system loading issues. The prioritization and operational changes are very nice and make a big difference; one thing that I find interesting is the behavior with our RAID systems, in that CAM has changed the outstanding tag queue size several times - including once revising it *upwards* (which I didn't expect to see). The performance improvements are substantial with CAM; it will be nice when that becomes the default. Have you tried building a release with the patches in? That would be an interesting exercise.. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980315055521.51883>