WRITE SAME always has a payload, regardless of the UNMAP bit value. For WRITE SAME with UNMAP=0, it's extremely important; that's how what to write is specified. For WRITE SAME with UNMAP=1, the device server is required to check that the payload matches the data that is returned for unmapped LBAs. lf LBPRZ=1 (read zeros for unmapped LBAs), that means checking that the payload has all zeros. In sbc3r33, this rule is tucked away in model section 4.7.3.4.3, not the command section 5.41. I would like to change that rule (it's a nuisance and a performance burden), but that's the current rule going into SBC-3 letter ballot. Changing WRITE SAME with UNMAP=1 to ignore the payload would provide essentially the same functionality as changing the UNMAP command to be mandatory, not just a hint; both approaches have been discussed. > -----Original Message----- > From: linux-scsi-owner@xxxxxxxxxxxxxxx [mailto:linux-scsi- > owner@xxxxxxxxxxxxxxx] On Behalf Of Christoph Hellwig > Sent: Thursday, 15 November, 2012 1:33 PM > To: Nicholas A. Bellinger > Cc: Christoph Hellwig; target-devel; linux-scsi; linux-kernel; Christoph Hellwig; > Martin K. Petersen > Subject: Re: [PATCH 3/3] target/iblock: Add WRITE_SAME w/ UNMAP=0 > emulation support > > On Thu, Nov 15, 2012 at 11:29:46AM -0800, Nicholas A. Bellinger wrote: > > Well at least for the latter that is because UNMAP=0 does not have a > > payload. ;) > > UNMAP=0 does have a payload, we just ignore it. In fact I was told > that targets should check for a completely zeroed sector sized payload > for it if being pedantic. I can't really find the justification for > that in the standard - the closest thing to it is the stance about > ignoring the unmap bit if the device is fully provisioned. > > -- > 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 -- 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
