In one of our SAN test labs where there is some storage controller error injection going on, I'm seeing some interesting behavior. We are getting into a scenario, when the target is coming back where we are going through SCSI scan for it and the Report LUNs we are issuing to it times out, so we fall back to a sequential LUN scan. When performing the sequential LUN scan, we end up adding a bunch of LUNs than we didn't previously see, 512 in fact. The target is reporting PQ=1, PDT=0 for every LUN that doesn't exist. When Report LUNs *does work*, it doesn't report these LUNs. In net, we end up with a different result if we do a sequential LUN scan compared to a report LUNs scan. Now, one could argue this is a defect in the SCSI target, since SPC says: The REPORT LUNS parameter data should be returned even though the device server is not ready for other commands. The report of the logical unit inventory should be available without incurring any media access delays. If the device server is not ready with the logical unit inventory or if the inventory list is null for the requesting I_T nexus and the SELECT REPORT field set to 02h, then the device server shall provide a default logical unit inventory that contains at least LUN 0 or the REPORT LUNS well known logical unit (see 8.2). A non-empty peripheral device logical unit inventory that does not contain either LUN 0 or the REPORT LUNS well known logical unit is valid. However, I'm still left wondering why we are adding PQ=1, PDT=0 devices in the sequential LUN scan at all. Are there media changer devices out there that we've seen respond like this? Even so, does it make sense to add PQ=1, PDT=0 LUNs for LUN > 0? Thanks, Brian -- Brian King Power Linux I/O IBM Linux Technology Center -- 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
