Re: Why REPORT LUN only for SCSI-2?

["Josef Möllers" <josef.moellers@fujitsu-siemens.com>]

Patrick Mansfield wrote:
> 
> On Wed, Jul 16, 2003 at 09:00:10AM +0200, Josef Möllers wrote:
> > Patrick Mansfield wrote:
> 
> > So, can I cast my vote to drop it? Or at least change it to a check for
> > SCSI_1.
> >
> > The code does work with SCSI-2 devices (some disks) which don't support
> > REPORT LUNs and IMHO devices which do support command code A0h for
> > anything other than REPORT LUNs _are_ broken.
> 
> But some broken devices might hang when sent a REPORT LUN command, and
> then we have to add a BFLAGS_NO_REPORT_LUN or some other hacks.

Isn't this what pretty much is in the device table? Information about
devices needing special treatment?
I agree that a SCSI-2 device which accepts REPORT LUNS is not really
standard, but a SCSI-2 device which doesn't accept REPORT LUNS should
reject it and that would be OK with the current code.

What good are all these auto-configuration features if they can't be
used?

> We could change BLIST_LARGELUN to be BLIST_SCSI_3, and take that to mean
> use REPORT LUN, and go up to the LLDD's max_lun (though I dislike adding
> anything to the device_info table, especially when these devices should
> report back as SCSI-3). Any multi-lun device that wants LUN > 8 better not
> hang on a REPORT LUN.

I know that these devices should report back as SCSI-3, but if the
vendors don't want to re-certify their devices for SCSI-3 compliancy, I
can't force them to do so, so we are stuck with FC devices reporting
more than 8 LUNs on SCSI-2.
REPORT LUNS is a clean way to handle LUNs: on devices which support it,
you don't even look at non-existing LUNs!

Section 7.1.1 of S2-R10L states that "A target that receives a reserved
bit, field, or byte that is not zero or receives a reserved code value
shall terminate the command with CHECK CONDITION status and the sense
key shall be set to ILLEGAL REQUEST." Thus, a SCSI-2 device which does
not properly reject REPORT LUNS yet chokes on it is not SCSI-2.

> > > Are the unconfigured LUNs showing up as if they were configured?
> >
> > Yes
> 
> Are the PQ values of the extra drives coming back as 1?  If so the devices
> will show up under sd but be offline. I can resend a patch for this, I got
> no comments last time it went out.

Apparently they do, because when I change the check for PQ == 3 to PQ !=
0, then I only see 4 LUNs.

[ ... ]

> > > Most disk/RAID arrays made in the last few years can configure whether
> > > they report back as SCSI-2 or SCSI-3. It would be best if you could change
> > > the device to report as SCSI-3.
> > >
> > > Even some SCSI disk drives are capable of reporting back as SCSI-2 or
> > > SCSI-3.
> >
> > No, unfortunately we cannot change this. I've tried, but the vendors
> > (these are OEM parts, it's not only the MYLEX thingies shown above)
> > refused.
> > I guess (I haven't dug into this deep enough, I'm not a standards
> > person) is that the parts aren't 100% SCSI-3, connected to a
> > FibreChannel HA. They are capable of addressing more than 8 LUNs.
> > Adding them to the device_table doen't really work, because then we get
> > 128 LUNs showing up and I have seen pretty large configurations with
> > several RAID boxes connected so we run out of device numbers.
> 
> For linux 2.6 SCSI-3 (generally) means we will send a REPORT LUN, and we
> will allow sequential scans past lun 8, and that would be fine in your
> case.

Not quite, since the devices we're talking abour say they're SCSI-2!

> You mean making the device BLIST_SPARSELUN in the scsi_static_device_list
> or device_info gives you 128 LUNs?

On some devices (a colleague reports this for an EMC 4700), yes it does.
That's one of our main problems.

As a side note (probably starting a new thread) why does BLIST_LARGELUN
override max_scsi_luns? If I specify on the command line that I want
only 8 LUNs, I want only 8 LUNs and BLIST_LARGELUN overrides this with
the HA's max_lun.

Josef
-- 
Josef Möllers (Pinguinpfleger bei FSC)
	If failure had no penalty success would not be a prize
						-- T.  Pratchett
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html