[PATCH] scsi_devinfo: update Hitachi entries

[PATCH] scsi_devinfo: update Hitachi entries

[Takahiro Yasui]

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 <tyasui@redhat.com>
---
 drivers/scsi/scsi_devinfo.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

Index: linux-2.6.30-rc7/drivers/scsi/scsi_devinfo.c
===================================================================
--- linux-2.6.30-rc7.orig/drivers/scsi/scsi_devinfo.c
+++ 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},

Re: [PATCH] scsi_devinfo: update Hitachi entries

[James Bottomley]

On Mon, 2009-06-01 at 12:46 -0400, Takahiro Yasui wrote:
>  	{"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

Re: [PATCH] scsi_devinfo: update Hitachi entries

[Takahiro Yasui]

James Bottomley wrote:
> On Mon, 2009-06-01 at 12:46 -0400, Takahiro Yasui wrote:
>>  	{"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.

Re: [PATCH] scsi_devinfo: update Hitachi entries

[James Bottomley]

On Mon, 2009-06-01 at 13:38 -0400, Takahiro Yasui wrote:
> James Bottomley wrote:
> > On Mon, 2009-06-01 at 12:46 -0400, Takahiro Yasui wrote:
> >>  	{"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.

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

Re: [PATCH] scsi_devinfo: update Hitachi entries

[Takahiro Yasui]

Hi James,

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

Re: [PATCH] scsi_devinfo: update Hitachi entries

[Takahiro Yasui]

On 06/03/09 12:40, Takahiro Yasui wrote:
> http://marc.info/?l=linux-scsi&m=114366299120761&w=2
>> - 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.

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

Thanks,
Taka