> -----Original Message----- > From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Saturday, July 26, 2014 12:25 PM > To: KY Srinivasan > Cc: Martin K. Petersen; Sitsofe Wheeler; Christoph Hellwig; > gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; > de...@linuxdriverproject.org; oher...@suse.com; a...@canonical.com; > jasow...@redhat.com; jbottom...@parallels.com; linux- > s...@vger.kernel.org > Subject: Re: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests > > >>>>> "KY" == KY Srinivasan <k...@microsoft.com> writes: > > >> Great! I'd just like to have a reasonable level of confidence in > >> what's happening down the stack before I entertain turning something > >> on that's not being properly advertised. > > KY> As I look at the output of inquiry between Linux on Hyper-V and > KY> native Linux, is not specifying conformance level the main issue? > > The main problem for this particular use case (aside from the issue we've > already addressed) is that the passthrough device (SATA SSD) has > LBPME=0 in the READ CAPACITY(16) response. The LBP VPD is correctly > provided with LBPU flag set but because LBPME is reported as disabled we > will not attempt to issue UNMAP commands to the device.
Had a chance to chat with the Windows sscsi folks. Here is their response: "At the time thin-provisioning was defined, the discovery information was first proposed in READ CAPACITY 16 command. And then moved into the new dedicated VPD page - B2h. You can see the information reported in this VPD page is richer than READ CAPACITY 16 command. As this transition happened during we added the feature, Windows uses the newer method that based on VPD page B2h. It looks Linux tries to use both new and old method which is weird to me." Would it make sense for us to work around this issue for Linux on Hyper-V (just use the VPD page instead of looking at the output of READ CAPACITY)? Regards, K. Y > > -- > Martin K. Petersen Oracle Linux Engineering _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
