On 13-04-07 12:15 PM, James Bottomley wrote:
On Sun, 2013-04-07 at 11:59 -0400, Douglas Gilbert wrote:
On 13-04-07 10:49 AM, James Bottomley wrote:
On Sun, 2013-04-07 at 15:31 +0200, Hannes Reinecke wrote:
On 04/06/2013 11:08 AM, James Bottomley wrote:
On Fri, 2013-03-15 at 10:46 +0100, Hannes Reinecke wrote:
SAM advertises the use of a Well-known LUN (W_LUN) for scanning.
As this avoids exposing LUN 0 (which might be a valid LUN) for
all initiators it is the preferred method for LUN scanning on
some arrays.
So we should be using W_LUN for scanning, too. If the W_LUN is
not supported we'll fall back to use LUN 0.
For broken W_LUN implementations a new blacklist flag
'BLIST_NO_WLUN' is added.
Well, we could do this, but I don't really see the point. By the time
we get into the report lun code, we've already probed LUN 0, so it's as
goeod as any for a REPORT LUN scan.
Did we? I thought I had avoided that and directly went for probing
W_LUN _first_.
Will be cross-checking.
What worries me slightly about the W-LUN is that for the first time
we'll be assuming a device supports a particular address method
(Extended Logical Unit addressing) rather than treating LUNs as opaque
handles we keep and pass back to the target. I appreciate you now have
a blacklist for failures, but if we didn't use W-LUNs we wouldn't need
that blacklist.
So could you answer two questions clearly:
1. What does this buy us over the current LUN0 method? I don't see
LUN0 might be a valid LUN being a convincing reason.
LUN masking.
Some HBAs / virtualised devices use LUN masking to forward LUNs to the
virtual machines.
So for LUN0 you have the choice of exposing it to every virtual machine,
meaning you cannot assign a device to LUN0, or have LUN0 as a no-device
LUN which then can be exposed to every virtual machine.
That shouldn't matter, should it? The spec says that even a masked LUN
must respond to an inquiry (with PQ indicating appropriate
inaccessibility).
Which spec? I haven't seen a mention of LUN masking
in any SCSI spec and I just rechecked SAM-2,3,4 and 5.
Looked at FCP-4 as well.
It's not called LUN Masking; it's called access control, although the
ACLs are referred to as LUN masks.
At which point you run into hardware limitations, as not every storage
array allow for the first option.
And not every LUN masking implementation allows you to expose a single
LUN to several virtual machines. So you might be screwed either way.
This was the main reason why zfcp could not use the standard LUN
scanning method like every other HBA LLDD and had to resort to manual
LUN activation.
So this is an out of spec implementation of LUN masking ... as in it
doesn't respond correctly to an INQUIRY?
No specs apply that I can see.
SPC-3 Section 8.3 "Access Controls"
spc4r36f.pdf section 8.3.1.2 [Overview]
"Access controls are handled in the SCSI target device by
an access controls coordinator located at the ACCESS CONTROLS
well known logical unit. The access controls coordinator also
may be accessible via LUN 0. The access controls coordinator
associates a specific LUN to a specific logical unit depending
on which initiator port accesses the SCSI target device and
whether the initiator port has access rights to the
logical unit."
That seems to strengthen the argument for going the W_LUN route.
Doug Gilbert
2. What devices have you actually tested this on?
Netapp FAS, HP EVA, HP P2000 / MSA, EMC Clariion.
But as mentioned, I'll be rechecking the patch.
We should _not_ try to probe LUN0 first, but rather send REPORT_LUNS to
the W_LUN directly. If it responds, good. If not, we'll fall back to LUN0.
I don't think we can ever do that ... what about SCSI 2 devices that
don't support REPORT LUNS or USB devices that will crash on it? We
might be able to try a host type whitelist, where if we were a USB or
traditional bus host (SPI) we never try this, but if we're a modern one
(SAS, FC) we do.
The VERSION field (byte 2) of an INQUIRY response is always
available, even on USB storage devices which usually claim
SCSI-2 compliance:
2 == (rsp_buff[2] & 0x7)
So this is the chicken and egg problem: if we haven't probed the target
at all, how do we know it's SCSI-2? If we do an initial probe, we have
to do it as an INQUIRY to LUN0 and we end up in the same situation we
are now. That's why I suggested a host bus type parameter if we want to
do REPORT LUNS probes.
No need to try REPORT LUNS on such devices.
Are there any SCSI-1 devices still out there?
I don't have any (last one burned out a while ago).
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
