Re: [PATCH 2/3] [SCSI] storvsc: Add Hyper-V logical block provisioning tests

[James Bottomley <jbottomley@parallels.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2528 bytes --]

On Thu, 2014-07-24 at 08:56 +0100, Sitsofe Wheeler wrote:
> Microsoft Hyper-V targets currently only claim SPC-2 compliance / no
> compliance indicated even though they implement post SPC-2 features
> which means those features are not tested for. Add a blacklist flag to
> Hyper-V devices that forces said testing.

This description is misleading: you don't force the test now, you force
the driver to send unmap commands down to the device.

> See https://lkml.org/lkml/2014/7/21/627 for the previous version of this
> patch and https://lkml.org/lkml/2014/7/23/615 for example devices.
> 
> Original-patch-by: K. Y. Srinivasan <kys@microsoft.com>
> Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
> ---
>  drivers/scsi/storvsc_drv.c | 10 +++-------
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 5ad2810..88b7173 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -326,8 +326,6 @@ MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer size (bytes)");
>   */
>  static int storvsc_timeout = 180;
>  
> -static int msft_blist_flags = BLIST_TRY_VPD_PAGES;
> -
>  #define STORVSC_MAX_IO_REQUESTS				200
>  
>  static void storvsc_on_channel_callback(void *context);
> @@ -1444,12 +1442,10 @@ static int storvsc_device_configure(struct scsi_device *sdevice)
>  	sdevice->no_write_same = 1;
>  
>  	/*
> -	 * Add blist flags to permit the reading of the VPD pages even when
> -	 * the target may claim SPC-2 compliance. MSFT targets currently
> -	 * claim SPC-2 compliance while they implement post SPC-2 features.
> -	 * With this patch we can correctly handle WRITE_SAME_16 issues.
> +	 * Forcefully enable logical block provisioning testing.
>  	 */
> -	sdevice->sdev_bflags |= msft_blist_flags;
> +	sdevice->sdev_bflags |= BLIST_TRY_LBP;
> +	sdevice->try_lbp = 1;

Really no way to this one.  You're forcing unmap support on every
hyper-v device; including spinning rust pass through ones which won't
support it.  The hyper-v storage interface has proven to be somewhat
fragile, so it may explode when the device tries to send illegal command
sense back.

If you have a specific IDENTITY string for a faulty SSD that fails to
report unmap support correctly, then we could quirk for that, but not
everything attached to the hyper-v driver.

James

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥