Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16

["Martin K. Petersen" <martin.petersen@oracle.com>]

>>>>> "hch" == hch@infradead org <hch@infradead.org> writes:

(Back from vacation: Bear with me while I'm catching up on two weeks of
linux-scsi stuff...)

hch> I think the problem is a differnet one.  If we have the logical
hch> provisioning EVPD it configures what method to use, but if we don't
hch> have one we simply check for a max unmap blocks field, and if
hch> that's not present use WRITE SAME.

Yeah, that was done to accommodate the devices out there that predate
the LBP VPD. There sadly are several still. And it's hard to motivate
people to update their storage array firmware even when updates are
readily available.

hch> The patch checks the no_write_same flag before doing that, for
hch> which we also have to do the write_same setup before the discard
hch> setup in sd_revalidate_disk.

The no_write_same was introduced to disable the REQ_WRITE_SAME use case
where we have no INQUIRY/READ CAPACITY/VPD flags to key off of to
determine whether it is safe to send the commands.

no_write_same does not preclude the REQ_DISCARD variants of
WRITE_SAME. Those are gated by the discard heuristics exclusively.

So first of all I'd like to know whether it's a WRITE SAME(16) or a
WRITE SAME(16) with the UNMAP bit set that's coming down.

hch> Ky: does hyperv support UNMAP?  If so any idea why it doesn't set
hch> the maximum unmap block count field in the EVPD?

We shouldn't be sending down WRITE SAME(16) with the UNMAP bit set
unless the device sets LBPME=1 in the READ CAPACITY(16) response.

So what does the storsvc report as its thin provisioning capabilities?

-- 
Martin K. Petersen	Oracle Linux Engineering