Message-ID: <523331FF.40609@interlog.com>
Date:	Fri, 13 Sep 2013 11:40:47 -0400
From:	Douglas Gilbert <dgilbert@...erlog.com>
To:	Andy Whitcroft <apw@...onical.com>
CC:	"James E.J. Bottomley" <JBottomley@...allels.com>,
	"K. Y. Srinivasan" <kys@...rosoft.com>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	Ben Howard <ben.howard@...onical.com>,
	linux-scsi@...r.kernel.org, devel@...uxdriverproject.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] Hyper-V TRIM support

On 13-09-13 08:58 AM, Andy Whitcroft wrote:
> tl;dr -- enable TRIM support for Hyper-V emulated disks.
>
> The Hyper-V hypervisor can support TRIM for its devices, advertising this
> via the appropriate VPD pages.  However the emulated disks only claim
> to be SPC-2 devices.  According to the specs VPD pages (in general) did
> exist at SPC-2 but the specific pages we interogate for the TRIM support

VPD pages are found in SPC (ANSI INCITS 301-1997) and many of its
drafts. By SPC-2 (ANSI INCITS 351-2001) the "supported VPD pages"
VPD page (0x0) ** and the "device identification" VPD page (0x83)
were mandatory (in SPC those pages were optional). So that is
approaching 20 years for manufacturers to get used to VPD pages.

TRIM is a T13 term (ATA/SATA) that was introduced after 2001
(i.e. after SBC-2). The corresponding SCSI term is now
"Logical Block Provisioning" (LBP). This covers the SCSI
UNMAP command (closest thing to TRIM) and the SCSI WRITE SAME
command which contains LBP options.

LBP capability was originally reported in the SCSI READ
CAPACITY(16) command (but not the more common READ
CAPACITY(10) command); namely the LBPME and LBPRZ bits. Those
bits have been renamed *** during the lifetime of SBC-3 drafts.
Those bits and a lot of additional LBP information are now
found in two VPD pages: "Block Limits" (0xb0) and "Logical
Block Provisioning" (0xb2).


After a 36 byte standard INQUIRY response, unless the
compliance is stone age (e.g. SCSI-2 or earlier) then
a 36 byte INQUIRY with the EVPD bit set and page=0
should be pretty safe. Check the response carefully
as USB devices will often ignore the EVPD bit and respond
with a standard INQUIRY response. Forget any such devices.
Now look for either of those LBP supporting VPD pages.
There should not be too many devices that support neither
and do LBP.

Doug Gilbert


**  some vendors do not include their own vendor specific VPD
     pages in the "Supported VPD pages" VPD page. Grrr

*** those bits were previously named TPE and TPRZ

> did not until SPC-3 therefore the kernel avoids reading the relevant pages
> for SPC-2 devices and prevents TRIM from being offered for these devices.
> Additionally at SPC-2 we prefer ReadCapacity10 over ReadCapacity16 and
> unless we use RC16 we will not identify the device as TRIM capable also
> preventing TRIM being offered.
>
> As the VPD page zero does list which pages are valid for each device, it
> could be argued that we could simply attempt to use these pages for all
> devices which claim to be SPC-2 and above.  While this seems valid the
> code documents a number of devices which take badly to having even VPD
> page 0 interogated even when supposedly supported.  Therefore it seems
> appropriate to add a scsi device flag to allow a device to request SPC-3
> VPD pages be used when only at SPC-2.
>
> Similarly for the ReadCapacity selection it seems dangerous to invert
> the order for all SPC-2 devices.  So it seems appropriate to add a scsi
> device flag to request we try RC16 before RC10 (mirroring the existing
> flag for the opposite).
>
> The following four patches add the two scsi device flags and select those
> flags for the Hyper-V emulated disks.





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists