Re: [PATCH] sd: always scan VPD pages if thin provisioning is enabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/25/2017 03:27 PM, Ewan D. Milne wrote:
> On Wed, 2017-01-25 at 11:38 +0100, Hannes Reinecke wrote:
>> On 01/25/2017 11:23 AM, Christoph Hellwig wrote:
>>> On Wed, Jan 25, 2017 at 08:26:05AM +0100, Hannes Reinecke wrote:
>>>> For any device with an older SCSI revision we might not
>>>> be scanning VPD pages, which results in a wrongly configured
>>>> discard mode if thin provisioned is enabled.
>>>> According to sbc3 any thin provisioned device (ie devices which
>>>> have the LBPME bit set in the output of READ CAPACITY(16)) need
>>>> to support VPD pages. So this patch always enables VPD pages
>>>> even for older SCSI revisions if thin provisioning is enabled.
>>>
>>> Can you explain what you need this for?  A device with a per-SBC3
>>> revision that wants us to use UNMAP?
>>>
>> Some storage arrays essentially lie about the SCSI revision (most
>> notably Hitachi :-), and some claim to support SPC-2 (or even SPC) but
>> support newer features, too. Most notably VPD pages support.
>> In this case it was an HP EVA claiming to support SPC-2 only, but
>> providing thin provisioning.
> 
> Um, isn't this why we added:
> 
> commit c1d40a527e885a40bb9ea6c46a1b1145d42b66a0
> Author: Martin K. Petersen <martin.petersen@xxxxxxxxxx>
> Date:   Tue Jul 15 12:49:17 2014 -0400
> 
>     scsi: add a blacklist flag which enables VPD page inquiries
> 
> (well, it was for storvsc, but we could add an entry for the HP EVA)
> 
I knew someone would raise this objection :-)

Thing is, setting 'WS16' here is arguably wrong, as LPBME just means
'logical block provisioning management enabled', not 'WRITE SAME 16 with
UNMAP' supported.

And we've set the restriction for scanning VPD pages rather high by
moving it to at least SPC-3; meaning we lose out on all SPC-2 devices
with logical block provisioning.

So rather than blacklisting each and every device (and incurring loads
of customer calls) I'd rather fix it once and for all.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@xxxxxxx			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux