> -----Original Message----- > From: Martin K. Petersen [mailto:martin.petersen@xxxxxxxxxx] > Sent: Friday, July 11, 2014 5:54 AM > To: hch@xxxxxxxxxxxxx > Cc: James Bottomley; KY Srinivasan; linux-kernel@xxxxxxxxxxxxxxx; > devel@xxxxxxxxxxxxxxxxxxxxxx; apw@xxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx; > linux-scsi@xxxxxxxxxxxxxxx; ohering@xxxxxxxx; jasowang@xxxxxxxxxx > Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16 > > >>>>> "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? Given that our current Host (ws2012 r2) advertises SPC-2 compliance, Linux does not even query this page. We support UNMAP. We just prototyped a host where we advertised SPC-3 compliance and Linux queries the EVPD page and does not use WRITE_SAME_16 K. Y -- 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