Re: [PATCH] Fix COMPARE_AND_WRITE but leave it disabled.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux SCSI]     [Linux RAID]     [Linux Clusters]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]

  Powered by Linux