On Mon, Jun 5, 2017 at 10:49 AM, Bart Van Assche <Bart.VanAssche@xxxxxxxxxxx> wrote: > A quote from the SBC-4 section about VERIFY(10): "If the byte check (BYTCHK) > field is set to 00b, then no Data-Out Buffer transfer shall occur". In other > words, if a VERIFY or WRITE VERIFY command is received with BYTCHK=0, > transferring the Data-Out buffer is not only superfluous it is also against > the SCSI specs. I think this is true for VERIFY; but WRITE VERIFY is not so clear. It looks to me like the SBC-4r13 description of WRITE VERIFY is broken. It refers to VERIFY for the definition of BYTCHK=01, but the definition in VERIFY refers to a CDB field that does not exist in the WRITE VERIFY CDB (VERIFICATION LENGTH). In WRITE VERIFY the most similar field is TRANSFER LENGTH. I take that to be intended as the amount of data to be written during the WRITE step. Since the spec refers to the nonexistent VERIFICATION LENGTH field for BYTCHK=01, we have to guess that they intend the TRANSFER LENGTH to be used also as the length of the VERIFY step, when BYTCHK=01. In WRITE VERIFY with BYTCHK=00, I think we must consider the TRANSFER LENGTH (usually nonzero) to apply to the WRITE step, no matter the setting of BYTCHK. Since the spec provides the BYTCHK field for WRITE VERIFY and refers to its definition in VERIFY, I take that to mean the intention is that BYTCHK=00 be treated as with VERIFY; in other words, the VERIFY step ignores TRANSFER LENGTH (even though the WRITE step uses it), and the VERIFY step checks the protection information based on the VRPROTECT field in the CDB (WRPROTECT in the WRITE CDB), as described in the VERIFY section. I think the spec is broken here, and this is my plausible interpretation of the intent. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
