James,
On Wed, Jul 01, 2009 at 07:33:32PM +0000, James Bottomley wrote:
> > --- root.orig/drivers/scsi/scsi_devinfo.c
> > +++ root/drivers/scsi/scsi_devinfo.c
> > @@ -152,7 +152,7 @@ static struct {
> > {"DGC", "RAID", NULL, BLIST_SPARSELUN}, /* Dell PV 650F, storage on LUN 0 */
> > {"DGC", "DISK", NULL, BLIST_SPARSELUN}, /* Dell PV 650F, no storage on LUN 0 */
> > {"EMC", "Invista", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
> > - {"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_FORCELUN},
> > + {"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_REPORTLUN2},
>
> You don't actually need SPARSE or LARGELUN ... that's implied by
> REPORTLUN2, so only REPORTLUN2 is needed here.
When I created the patch, all SYMMETRIXes that I had ever been exposed
to did support REPORT_LUNs, but I was not sure that every single
SYMMETRIX out there would actually support it. So in case some old
SYMMETRIX would not and the kernel would fall back to sequential
scanning, we would still find all LUNs by not dropping SPARSELUN
and LARGELUN. (Dropping FORCELUN on the other hand was absolutely right;
the flag is broken by design anyway and should never be used.)
So leaving in SPARSELUN and LARGELUN was not an oversight, but really
trying to be conservative.
If you have additional insight (you positively know that every SYMMETRIX
does support REPORT_LUNS) or you want to force possible devices that
do not support it into the open by breaking them, then remove the two
flags.
> > {"EMULEX", "MD21/S2 ESDI", NULL, BLIST_SINGLELUN},
> > {"easyRAID", "16P", NULL, BLIST_NOREPORTLUN},
> > {"easyRAID", "X6P", NULL, BLIST_NOREPORTLUN},
Best,
--
Kurt Garloff, VP OPS Partner Engineering -- Novell Inc.
Attachment:
pgpt4pNNzABON.pgp
Description: PGP signature
