On 08/21/2015 12:11 AM, Brian King wrote: > 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. > Hey, join the club. I've had a similar array, which were returning a default inventory during bootup. Leaving us with no chance to detect if the default inventory was the correct one or not. I even posted a patch some time ago; if you wish I can drag it out. > 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? > Yes, unfortunately we need this. NetApp arrays have a habit of returning 'PQ=1' for unconnected LUN 0, even though higher LUNs are present. So we need to add devices for PQ=1, otherwise we wouldn't be able to scan them. We _might_ be able to tweak this by ignoring devices with PQ=1 and LUN!=0; however, it might break other things. As a net result, do avoid sequential scan if at all possible. I would rather work on getting REPORT LUNs to reliably report data. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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
