Eric Youngdale wrote:
> Originally when I first added support for logical units, we only did the
> INQUIRY we had problems with devices which falsely indicated the presence of
> devices on all logical units. I suppose it was mainly because I failed to
In my previous company's test lab we still up to last year often found devices
that didn't return the right INQUIRY peripheral qualifier/device type to
indicate a LUN > 0 isn't supported. The only option I know of is to continue
using the drivers/scsi/scsi.c BLIST_NOLUN option for these devices when they
are found.
> one. The point is that this sort of monstrosity destroyed the symmetry
> that theoretically should exist where each logical unit is in theory a sort
> of clone of the other logical units for that device. Do these sorts of
> things still exist any more?
>
> Anyways, my long-winded answer is that I gather from what you are saying
> above that we should first do an INQUIRY, and if the INQUIRY succeeds, then
> we perform a scan on all luns for the device in question.
You're right; A multi-LUN device's LUNs definitely do not have to be all of
the same device type. So contraty to what I said the Mid-Level driver would
still scan all LUNs of a device. But it should top scanning for LUNs once the
INQUIRY peripheral qualifier/device type indicates a LUN isn't present - there
are never holes in the LUN address space. Or if the LUN 0 INQUIRY data
indicates LUN 0 supports REPORT LUNS , then REPORT LUNS should be used to
detect the device's LUNs.
So after each LUN is detected, then the the Mid-Level driver would pass the
device to the right Upper-Level driver (or all of them as it does now). The
Upper-Level driver would honor the INQUIRY Medium Changer bit and know that it
wouldn't make sense to issue a TEST UNIT READY for each LUN of the Medium
Changer device.
Bob Frey
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
