Re: [PATCH] scsi_devinfo: update Hitachi entries

[Takahiro Yasui <tyasui@redhat.com>]

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.