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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
