SCSI scanning behavior

[Brian King <brking@linux.vnet.ibm.com>]

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