* Why REPORT LUN only for SCSI-2? @ 2003-07-15 14:18 Josef Möllers 2003-07-15 14:39 ` Patrick Mansfield 0 siblings, 1 reply; 9+ messages in thread From: Josef Möllers @ 2003-07-15 14:18 UTC (permalink / raw) To: linux-scsi 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why REPORT LUN only for SCSI-2? 2003-07-15 14:18 Why REPORT LUN only for SCSI-2? Josef Möllers @ 2003-07-15 14:39 ` Patrick Mansfield 2003-07-16 7:00 ` Josef Möllers 0 siblings, 1 reply; 9+ messages in thread From: Patrick Mansfield @ 2003-07-15 14:39 UTC (permalink / raw) To: Josef Möllers; +Cc: linux-scsi 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why REPORT LUN only for SCSI-2? 2003-07-15 14:39 ` Patrick Mansfield @ 2003-07-16 7:00 ` Josef Möllers 2003-07-16 19:35 ` Patrick Mansfield 0 siblings, 1 reply; 9+ messages in thread From: Josef Möllers @ 2003-07-16 7:00 UTC (permalink / raw) To: Patrick Mansfield; +Cc: linux-scsi 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why REPORT LUN only for SCSI-2? 2003-07-16 7:00 ` Josef Möllers @ 2003-07-16 19:35 ` Patrick Mansfield 2003-07-17 8:55 ` Josef Möllers 0 siblings, 1 reply; 9+ messages in thread From: Patrick Mansfield @ 2003-07-16 19:35 UTC (permalink / raw) To: Josef Möllers; +Cc: linux-scsi 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why REPORT LUN only for SCSI-2? 2003-07-16 19:35 ` Patrick Mansfield @ 2003-07-17 8:55 ` Josef Möllers 2003-07-17 18:49 ` Kurt Garloff 0 siblings, 1 reply; 9+ messages in thread From: Josef Möllers @ 2003-07-17 8:55 UTC (permalink / raw) To: Patrick Mansfield; +Cc: linux-scsi, Wichert, Gerhard 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why REPORT LUN only for SCSI-2? 2003-07-17 8:55 ` Josef Möllers @ 2003-07-17 18:49 ` Kurt Garloff 2003-07-17 23:46 ` Patrick Mansfield 2003-07-18 6:38 ` Josef Möllers 0 siblings, 2 replies; 9+ messages in thread From: Kurt Garloff @ 2003-07-17 18:49 UTC (permalink / raw) To: Josef Möllers; +Cc: Patrick Mansfield, linux-scsi, Wichert, Gerhard [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why REPORT LUN only for SCSI-2? 2003-07-17 18:49 ` Kurt Garloff @ 2003-07-17 23:46 ` Patrick Mansfield 2003-07-18 6:38 ` Josef Möllers 1 sibling, 0 replies; 9+ messages in thread From: Patrick Mansfield @ 2003-07-17 23:46 UTC (permalink / raw) To: Kurt Garloff, Josef Möllers, linux-scsi, Wichert, Gerhard 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why REPORT LUN only for SCSI-2? 2003-07-17 18:49 ` Kurt Garloff 2003-07-17 23:46 ` Patrick Mansfield @ 2003-07-18 6:38 ` Josef Möllers 1 sibling, 0 replies; 9+ messages in thread From: Josef Möllers @ 2003-07-18 6:38 UTC (permalink / raw) To: Kurt Garloff; +Cc: Patrick Mansfield, linux-scsi, Wichert, Gerhard 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why REPORT LUN only for SCSI-2?
@ 2003-07-18 0:25 David.Egolf
0 siblings, 0 replies; 9+ messages in thread
From: David.Egolf @ 2003-07-18 0:25 UTC (permalink / raw)
To: linux-scsi, linux-scsi-owner
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
^ permalink raw reply [flat|nested] 9+ messages in threadend of thread, other threads:[~2003-07-18 6:23 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-07-15 14:18 Why REPORT LUN only for SCSI-2? Josef Möllers 2003-07-15 14:39 ` Patrick Mansfield 2003-07-16 7:00 ` Josef Möllers 2003-07-16 19:35 ` Patrick Mansfield 2003-07-17 8:55 ` Josef Möllers 2003-07-17 18:49 ` Kurt Garloff 2003-07-17 23:46 ` Patrick Mansfield 2003-07-18 6:38 ` Josef Möllers 2003-07-18 0:25 David.Egolf
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.