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