SBC: 4.27 Model for uninterrupted sequences on LBA ranges Direct-access block devices may perform commands that require an uninterrupted series of actions to be performed on a specified range of LBAs. The uninterrupted sequences are relative to the consistency of the data in the logical blocks specified by the particular command that requires the uninterrupted sequence. The uninterrupted sequences do not impact the processing of commands that access logical blocks other than those specified in the command requiring an uninterrupted sequence. The task attribute (see SAM-5) controls interactions between multiple commands. Commands with uninterrupted sequences on LBA ranges are: COMPARE AND WRITE; ORWRITE (16); ORWRITE (32); XDWRITEREAD (10); XDWRITEREAD (32); XPWRITE (10); and XPWRITE (32). On Sun, Dec 9, 2012 at 4:41 AM, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > On Fri, 7 Dec 2012 20:31:26 +0100 > Arne Redlich <arne.redlich@xxxxxxxxxxxxxx> wrote: > >> 2012/12/7 Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx>: >> > Fix the compare and write opcode but leave it disabled. >> > It looks like consumers like vmware may be assuming that IF >> > compare and write is present and if it works, then the target will also >> > implement other opcodes like XCOPY etc. >> > >> > So lets fix the command so that it works, but wait with enabling it >> > until we have everything else that the main consumer of this rare opcode >> > expects and wants. >> > >> > Signed-off-by: Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx> >> > --- >> > usr/bs_rdwr.c | 21 +++++++++++++++++---- >> > 1 files changed, 17 insertions(+), 4 deletions(-) >> >> I suppose this fell through the cracks last time around since I didn't >> get any feedback: how is atomicity of the CAW guaranteed? AFAIU, >> another bs thread could modify the data while a CAW is going on, >> breaking the expected semantics. Or am I just overlooking something in >> the code? > > The spec requires such atomicity? Yeah, I'm too lazy to check the spec. -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
