Date: Fri, 2 Jul 1999 22:08:12 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: "Kenneth D. Merry" <ken@plutotech.com> Cc: gibbs@plutotech.com, scsi@freebsd.org Subject: Re: just so you all know how really whacky it can get... Message-ID: <Pine.BSF.4.05.9907022200470.1622-100000@semuta.feral.com> In-Reply-To: <199907030311.VAA57892@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I was impressed that it did as well as it did- really pretty good all told. > One thing I don't understand, though, is why any of those disks would even > respond on a LUN other than 0. You'd think they would do the normal thing > and just not respond to an inquiry. Disk breakage. The parallel SCSI ISP 7.63 f/w goes up to 32 luns. I don't allow it to (yet) go above 8 luns because there are far too many disks that just go apeshit- and this is a problem because there are a large number of RAID devices that really want use all 32 luns (for parallel SCSI). Think about all the devices that can't cope with non-zero luns at all. Now imagine that you're the f/w writer- if you handle greater than lun 0, you should handle all luns sensibly, right? Heh. You don't know f/w writers... > I think you're right, we probably need to do something about it. But > the REPORT LUNS command wouldn't help here, since that's a SCSI-3 command. > Unless you can change the definition on those drives. Even still, it > wouldn't help in all cases. > > One possible sequence of things we could do is: > > - attempt to change the definition of the device to SCSI-3 > - if that works, send the REPORT LUNS command > - probe only the luns returned > - if the change definition doesn't work, only probe up to N luns, > where N is no more than 7 or 16 (for FC) > > Does that even sound reasonable? I think I simply would skip the change definition- just try the REPORT LUNS command. Just because a command is specified in SCSI-3 doesn't mean that a SCSI-2 device won't decode it. But if you can do the change definition, that'd work too. That should unambiguously tell one what the number of supported luns are. Beyond that, I'm thinking that we need to move a bit more agressively on the runtime quirking we've been talking about and allow people to specify devices that *can* go above 8 or 16 luns. -matt 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?Pine.BSF.4.05.9907022200470.1622-100000>