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

[James Bottomley <jbottomley@parallels.com>]

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

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

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

James