>>>>> "hch" == hch@infradead org <hch@xxxxxxxxxxxxx> 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 -- 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
