[stgt] [PATCH] Fix COMPARE_AND_WRITE but leave it disabled.

[ronnie sahlberg]

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 at lab.ntt.co.jp> wrote:
> On Fri, 7 Dec 2012 20:31:26 +0100
> Arne Redlich <arne.redlich at googlemail.com> wrote:
>
>> 2012/12/7 Ronnie Sahlberg <ronniesahlberg at gmail.com>:
>> > 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 at gmail.com>
>> > ---
>> >  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 at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html