Re: SCSI scanning behavior

[Hannes Reinecke <hare@suse.de>]

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@suse.de			               +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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html