Re: [RFC] hv_storvsc: error handling.

[Stephen Hemminger <stephen@networkplumber.org>]

> > I will try it, but it can't work for two reasons.
> > First, the INVALID_LUN error is masked off on INQUIRY in current code.
> > Second, the scsi_device is instantiated already as part of scan probe process
> > before it gets here.  
> 
> Was the invalid LUN in the LUN0 position. Inquiry of LUN0 support (when LUN0 is not populated)
> was added only recently to address host side issue.

When probing the code probes with LUN 1, ...

There is a cause where kernel does INQUIRY on LUN0, it looks kernel is asking for
page code 80 which is optional "Unit Serial Number".  And then WS2016 is returning
an error and invalid sense data.  The old masking of errors caused kernel to
interpret sense data as Unit Serial Number which is also not good but looks harmless.

 
> > The best solution so far is:
> > 	- remove old INQUIRY/SENSE error masking
> > 	+ add new workaround for INQUIRY of device id on LUN 0
> > 	  which appears to be the reason for old masking
> > 	+ return errors on missing LUN
> > 	+ provide better transport services for hot remove (rather
> >           than detecting by failed I/O).  
> 
> This the mechanism used by the host for notifying LUN removal - invalid LUN error code.

This has a couple of problems. First, it means that hotplug doesn't occur until
an I/O is done. Second the current code was not being truthful to block layer.
If it has to handle hotplug in this manner, it should have still failed the I/O.
If application was using direct I/O it would want to know that write failed.

Perhaps the existing channel mechanism can be used as notification path.