Re: [PATCH][RFC] scsi: Use W_LUN for scanning

[James Bottomley <jbottomley@parallels.com>]

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"

> >>>        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