Why REPORT LUN only for SCSI-2?

Why REPORT LUN only for SCSI-2?

[Josef Möllers]

Hi,

Ist there a hard reason not to allow the REPORT LUNS command for SCSI-2
devices?
Are there actually some SCSI-2 devices which break on this command?

There are several devices (e.g. RAID) which tread carefull and claim
only SCSI-2 compliancy but support REPORT LUNS. It would make life
easier with these if REPORT LUNS would be generally available.
Eg I have a box which will happily accept INQUIRYs on LUNs 0-7 but
REPORT LUNS returns only the 4 configured LUNs.

-- 
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

Re: Why REPORT LUN only for SCSI-2?

[Patrick Mansfield]

On Tue, Jul 15, 2003 at 04:18:24PM +0200, Josef Möllers wrote:
> Hi,
> 
> Ist there a hard reason not to allow the REPORT LUNS command for SCSI-2
> devices?

No.

> Are there actually some SCSI-2 devices which break on this command?

Probably, given the range of SCSI devices out there.

> There are several devices (e.g. RAID) which tread carefull and claim
> only SCSI-2 compliancy but support REPORT LUNS. It would make life
> easier with these if REPORT LUNS would be generally available.
> Eg I have a box which will happily accept INQUIRYs on LUNs 0-7 but
> REPORT LUNS returns only the 4 configured LUNs.

Are the unconfigured LUNs showing up as if they were configured?

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.

-- Patrick Mansfield
-
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

Re: Why REPORT LUN only for SCSI-2?

[Josef Möllers]

Patrick Mansfield wrote:

> > Ist there a hard reason not to allow the REPORT LUNS command for SCSI-2
> > devices?

> No.

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.

> > There are several devices (e.g. RAID) which tread carefull and claim
> > only SCSI-2 compliancy but support REPORT LUNS. It would make life
> > easier with these if REPORT LUNS would be generally available.
> > Eg I have a box which will happily accept INQUIRYs on LUNs 0-7 but
> > REPORT LUNS returns only the 4 configured LUNs.
> 
> Are the unconfigured LUNs showing up as if they were configured?

Yes

These are the configured entries from /proc/scsi/scsi:

Host: scsi1 Channel: 00 Id: 01 Lun: 00
  Vendor: MYLEX    Model: DAC960FL 18000T0 Rev: 5426
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 01 Lun: 01
  Vendor: MYLEX    Model: DAC960FL 18000T0 Rev: 5426
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 01 Lun: 02
  Vendor: MYLEX    Model: DAC960FL 18000T0 Rev: 5426
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 01 Lun: 03
  Vendor: MYLEX    Model: DAC960FL 15464T0 Rev: 5426
  Type:   Direct-Access                    ANSI SCSI revision: 02

These are the unconfigured LUNs:

Host: scsi1 Channel: 00 Id: 01 Lun: 04
  Vendor: MYLEX    Model: DAC960FL         Rev: 5426
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 01 Lun: 05
  Vendor: MYLEX    Model: DAC960FL         Rev: 5426
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 01 Lun: 06
  Vendor: MYLEX    Model: DAC960FL         Rev: 5426
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 01 Lun: 07
  Vendor: MYLEX    Model: DAC960FL         Rev: 5426
  Type:   Direct-Access                    ANSI SCSI revision: 02

These last 4 Luns are not detected if I remove the SCSI_3 check at the
beginning of scsi_report_lun_scan().

> 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.

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

Re: Why REPORT LUN only for SCSI-2?

[Patrick Mansfield]

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. 

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.

> > 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.

You can easily tell if run with scsi scan logging, either boot with:

	scsi_mod.scsi_logging_level=0x00000180

Or before insmod of the adapter:

	echo scsi log scan 6  >/proc/scsi/scsi

> > 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.

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

-- Patrick Mansfield
-
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

Re: Why REPORT LUN only for SCSI-2?

[Josef Möllers]

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

Re: Why REPORT LUN only for SCSI-2?

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 3677 bytes --]

Hi,

On Thu, Jul 17, 2003 at 10:55:56AM +0200, Josef Möllers wrote:
> 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,

I would not say that a device that implements commands from newer
standards breaks the older one. Otherwise, the standards have not
well been defined w.r.t. backwards compatibility.

> but a SCSI-2 device which doesn't accept REPORT LUNS should
> reject it and that would be OK with the current code.

Sure.
But we would need a blacklist flag for broken devices.
On the other hand it would probably reduce the size of the blacklist
as BLIST_SPARSELUN | BLIST_LARGELUN devices could go away.

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

Well, this question should probably not be asked to Linux SCSI hackers
but to vendors who sell things that would not survive the simplest
SCSI compliance tests ... 

> > 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.

That could be a compromise, but I'd prefer to always try REPORT_LUNS if
the device is SCSI-2 or up. Or one could use additional indications like
the attachment to a host adapter that supports LUNS > 8. My guess would
be that there not that many broken FC devices out there. (GIven the
price tag that is attached to FC HW, this should be a reason to jump 
into the vendor's face.)

> REPORT LUNS is a clean way to handle LUNs: on devices which support it,
> you don't even look at non-existing LUNs!

Sure.

> > > 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.

Hmm, I was hoping that we'd have 64 bit device numbers to address this
when 2.6 is ready. For 2.4, we have patches to support dynamic block
device numbers and are able to support > 2000 disks.
http://www.suse.de/~garloff/scsi-many/

The patch can be redone for 2.6 of course, but I was hoping to see 
a nicer solution ...
What's the statuds on 64bit dev_t?

> > 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.

Looks like we need scsi-many for 2.6 ... 
Or does just changing the "Report Code" in REPORT_LUNS fix this?

> As a side note (probably starting a new thread) why does BLIST_LARGELUN
> override max_scsi_luns? 

It shouldn't. Did I really do this? (... checking 2.4 code ...)
No, I plead innocent.

> 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.

Sure. If I don't misparse the code, this should work in 2.4.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers                 SuSE Labs (Head)
SuSE Linux AG, Nuernberg, DE                            SCSI, Security

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: Why REPORT LUN only for SCSI-2?

[Patrick Mansfield]

On Thu, Jul 17, 2003 at 08:49:09PM +0200, Kurt Garloff wrote:

> > As a side note (probably starting a new thread) why does BLIST_LARGELUN
> > override max_scsi_luns? 
> 
> It shouldn't. Did I really do this? (... checking 2.4 code ...)
> No, I plead innocent.
> 
> > 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.
> 
> Sure. If I don't misparse the code, this should work in 2.4.

The code looks right in 2.6 also - if SCSI-3 or BLIST_LARGELUN, we use the
min of max_lun and max_scsi_luns; else (SCSI-2 and not large lun) the min
of 8, max_lun, and max_scsi_luns.

-- Patrick Mansfield

Re: Why REPORT LUN only for SCSI-2?

[Josef Möllers]

Kurt Garloff wrote:

> > As a side note (probably starting a new thread) why does BLIST_LARGELUN
> > override max_scsi_luns?
> 
> It shouldn't. Did I really do this? (... checking 2.4 code ...)
> No, I plead innocent.

Oops, I didn't check the info I got from a third party or I should go
and wash my ears B-{(
It's SPARSELUN which overrides max_scsi_luns:
	if (bflags & BLIST_SPARSELUN) {
		*max_dev_lun = shpnt->max_lun;
		*sparse_lun = 1;
                return 1;
        }
The objection still stands ...

-- 
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

Re: Why REPORT LUN only for SCSI-2?

[David.Egolf]

Hi,

On 07/17/2003 11:49 AM, Kurt wrote:

> Hmm, I was hoping that we'd have 64 bit device numbers to address this
> when 2.6 is ready. For 2.4, we have patches to support dynamic block
> device numbers and are able to support > 2000 disks.
> http://www.suse.de/~garloff/scsi-many/

I believe that he intended: http://www.suse.de/~garloff/linux/scsi-many/
for the url address.

David Egolf
Bull HN
Phoenix, AZ