scsi_devinfo: update Hitachi entries

PATCH In review Takahiro Yasui 2 participants 6 messages Jun 1, 2009 – Jun 27, 2009 SCSI

lore

Share & tools

lore

Takahiro Yasui

author

2009-06-01 16:43 UTC #0 lore raw

PATCH 1/1 scsi_devinfo: update Hitachi entries

Hi,

This is scsi_devinfo flag updates for the Hitachi storages.

Three models, OPEN-/DF400/DF500, can handle REPORT_LUN, and the BLIST_REPORTLUN2 flag needs to be set. DF600 returns ANSI 03h (SPC) and no flag is required.

Thanks,
---
Takahiro Yasui
Hitachi Computer Products (America), Inc.

Signed-off-by Takahiro Yasui <[email protected]>

---
 drivers/scsi/scsi_devinfo.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

drivers/scsi/scsi_devinfo.c +3 -4

Index: linux-2.6.30-rc7/drivers/scsi/scsi_devinfo.c
===================================================================
@@ -161,11 +161,10 @@ static struct {
 	{"Generic", "USB SD Reader", "1.00", BLIST_FORCELUN | BLIST_INQUIRY_36},
 	{"Generic", "USB Storage-SMC", "0180", BLIST_FORCELUN | BLIST_INQUIRY_36},
 	{"Generic", "USB Storage-SMC", "0207", BLIST_FORCELUN | BLIST_INQUIRY_36},
-	{"HITACHI", "DF400", "*", BLIST_SPARSELUN},
-	{"HITACHI", "DF500", "*", BLIST_SPARSELUN},
-	{"HITACHI", "DF600", "*", BLIST_SPARSELUN},
+	{"HITACHI", "DF400", "*", BLIST_REPORTLUN2},
+	{"HITACHI", "DF500", "*", BLIST_REPORTLUN2},
 	{"HITACHI", "DISK-SUBSYSTEM", "*", BLIST_ATTACH_PQ3 | BLIST_SPARSELUN | BLIST_LARGELUN},
-	{"HITACHI", "OPEN-E", "*", BLIST_ATTACH_PQ3 | BLIST_SPARSELUN | BLIST_LARGELUN},
+	{"HITACHI", "OPEN-", "*", BLIST_REPORTLUN2},
 	{"HITACHI", "OP-C-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
 	{"HITACHI", "3380-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
 	{"HITACHI", "3390-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},

James Bottomley

maintainer

2009-06-01 16:54 UTC #1 lore raw

drivers/scsi/scsi_devinfo.c static struct { · line 167

Quoted 3 lines · Takahiro Yasui

drivers/scsi/scsi_devinfo.c +1 -1

 	{"HITACHI", "DISK-SUBSYSTEM", "*", BLIST_ATTACH_PQ3 | BLIST_SPARSELUN | BLIST_LARGELUN},
-	{"HITACHI", "OPEN-E", "*", BLIST_ATTACH_PQ3 | BLIST_SPARSELUN | BLIST_LARGELUN},
+	{"HITACHI", "OPEN-", "*", BLIST_REPORTLUN2},

Can we drop the BLIST_ATTACH_PQ3? It was there for not only to get the sequential scan to work, but also so LUN0 would be registered with the OS (I think for some control purpose) which would no longer happen.

James

Takahiro Yasui

author

2009-06-01 17:35 UTC #2 lore raw

Quoted 8 lines · James Bottomley

drivers/scsi/scsi_devinfo.c static struct { · line 167
Quoted 3 lines · Takahiro Yasui
drivers/scsi/scsi_devinfo.c +1 -1
 	{"HITACHI", "DISK-SUBSYSTEM", "*", BLIST_ATTACH_PQ3 | BLIST_SPARSELUN | BLIST_LARGELUN},
-	{"HITACHI", "OPEN-E", "*", BLIST_ATTACH_PQ3 | BLIST_SPARSELUN | BLIST_LARGELUN},
+	{"HITACHI", "OPEN-", "*", BLIST_REPORTLUN2},
Can we drop the BLIST_ATTACH_PQ3? It was there for not only to get the sequential scan to work, but also so LUN0 would be registered with the OS (I think for some control purpose) which would no longer happen.

BLIST_ATTACH_PQ3 was added to "OPEN-E" in the following commit:
commit: 13f7e5acc8b329080672c13f05f252ace5b79825

---
Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but report a unknown device with PQ 3 on LUN 0. We still need to scan them, and most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug reference for an infamous example.
---

According to the commit, "OPEN-E" does not support REPORT_LUNS, but "OPEN-E" can handle REPORT_LUNS. In addition, other "OPEN-" models can do as well.

I would like to know in which case BLIST_ATTACH_PQ3 is required.

Thanks,
---
Takahiro Yasui
Hitachi Computer Products (America), Inc.

James Bottomley

maintainer

2009-06-01 20:06 UTC #3 lore raw

Quoted 20 lines · Takahiro Yasui

Quoted 8 lines · James Bottomley
drivers/scsi/scsi_devinfo.c static struct { · line 167
Quoted 3 lines · Takahiro Yasui
drivers/scsi/scsi_devinfo.c +1 -1
 	{"HITACHI", "DISK-SUBSYSTEM", "*", BLIST_ATTACH_PQ3 | BLIST_SPARSELUN | BLIST_LARGELUN},
-	{"HITACHI", "OPEN-E", "*", BLIST_ATTACH_PQ3 | BLIST_SPARSELUN | BLIST_LARGELUN},
+	{"HITACHI", "OPEN-", "*", BLIST_REPORTLUN2},
Can we drop the BLIST_ATTACH_PQ3? It was there for not only to get the sequential scan to work, but also so LUN0 would be registered with the OS (I think for some control purpose) which would no longer happen.
BLIST_ATTACH_PQ3 was added to "OPEN-E" in the following commit:
commit: 13f7e5acc8b329080672c13f05f252ace5b79825
---
Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but report a unknown device with PQ 3 on LUN 0. We still need to scan them, and most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug reference for an infamous example.
---

Quoted 5 lines

According to the commit, "OPEN-E" does not support REPORT_LUNS, but "OPEN-E" can handle REPORT_LUNS. In addition, other "OPEN-" models can do as well.
I would like to know in which case BLIST_ATTACH_PQ3 is required.

That, I believe is the question I asked you. If you don't know the answer, just leave the BLIST_ATTACH_PQ3 in. it's harmless for the report luns case and it will still attach a PQ disconnected LUN0, which was the original behaviour.

James

Takahiro Yasui

author

2009-06-03 16:37 UTC #4 lore raw

Hi James,

Quoted 6 lines

Quoted 1 line
I would like to know in which case BLIST_ATTACH_PQ3 is required.
That, I believe is the question I asked you. If you don't know the answer, just leave the BLIST_ATTACH_PQ3 in. it's harmless for the report luns case and it will still attach a PQ disconnected LUN0, which was the original behaviour.

According to the mail by which BLIST_ATTACH_PQ3 is introduced, those two issues were reported.

http://marc.info/?l=linux-scsi&m=114366299120761&w=2

Quoted 3 lines

- Blacklist flags are not used to do special handling if needed.
- If the device does NOT support the REPORT_LUNS scan, we won't see any LUN at all, as we don't even look for LUN 1 then.

In kernel 2.6.16, sequential_lun_scan() had a argument, lun0_res, and lun >=1 was not recognized when lun0 was not attached. Therefore, it seems that BLIST_ATTACH_PQ3 was necessary to pretend lun0 exists.

But if those two are the only reason to be solved, I don't think BLIST_ATTACH_PQ3 is necessary for storages which can handle REPORT_LUNS.

As you mentioned, leaving BLIST_ATTACH_PQ3 in the flag does not change the original behaviour, but I hope the BLIST_ATTACH_PQ3 flag is removed from OPEN-E so that lun0 is not installed when a storage returns PQ3 as other storages.

Again, I appreciate your comments.

Thanks,
---
Takahiro Yasui
Hitachi Computer Products (America), Inc.

Takahiro Yasui

author

2009-06-27 00:18 UTC #5 lore raw

Quoted 9 lines · Takahiro Yasui

http://marc.info/?l=linux-scsi&m=114366299120761&w=2
Quoted 3 lines
- Blacklist flags are not used to do special handling if needed.
- If the device does NOT support the REPORT_LUNS scan, we won't see any LUN at all, as we don't even look for LUN 1 then.
In kernel 2.6.16, sequential_lun_scan() had a argument, lun0_res, and lun >=1 was not recognized when lun0 was not attached. Therefore, it seems that BLIST_ATTACH_PQ3 was necessary to pretend lun0 exists.

Quoted 7 lines

But if those two are the only reason to be solved, I don't think BLIST_ATTACH_PQ3 is necessary for storages which can handle REPORT_LUNS.
As you mentioned, leaving BLIST_ATTACH_PQ3 in the flag does not change the original behaviour, but I hope the BLIST_ATTACH_PQ3 flag is removed from OPEN-E so that lun0 is not installed when a storage returns PQ3 as other storages.

I will evaluate BLIST_ATTACH_PQ3 flags on our storages, and post the result here. Please give me some time.

Thanks,
Taka