From: Mike Christie <michaelc@cs.wisc.edu>
To: Bart Van Assche <bvanassche@acm.org>,
linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
ceph-devel@vger.kernel.org, axboe@kernel.dk,
Douglas Gilbert <dgilbert@interlog.com>,
Robert Elliott <Elliott@hp.com>, Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH 0/5] block/scsi/lio support for COMPARE_AND_WRITE
Date: Sat, 18 Oct 2014 15:32:12 -0500 [thread overview]
Message-ID: <5442CE4C.9090301@cs.wisc.edu> (raw)
In-Reply-To: <544220C3.2010900@acm.org>
On 10/18/2014 03:11 AM, Bart Van Assche wrote:
> On 10/16/14 07:37, michaelc@cs.wisc.edu wrote:
>> The following patches implement the SCSI command COMPARE_AND_WRITE as
>> a new
>> bio/request type REQ_CMP_AND_WRITE. COMPARE_AND_WRITE is defined in the
>> SCSI SBC (SCSI block command) specs as:
>>
>> The COMPARE AND WRITE command requests that the device server perform the
>> following as an uninterrupted series of actions:
>>
>> 1) perform the following operations:
>> A) read the specified logical blocks; and
>> B) transfer the specified number of logical blocks from the
>> Data-Out
>> Buffer (i.e., the verify instance of the data is transferred
>> from the
>> Data-Out Buffer);
>>
>> 2) compare the data read from the specified logical blocks with the
>> verify
>> instance of the data; and
>> 3) If the compared data matches, then perform the following operations:
>> 1) transfer the specified number of logical blocks from the
>> Data-Out
>> Buffer (i.e., the write instance of the data transferred from
>> the
>> Data-Out Buffer); and
>> 2) write those logical blocks.
>
> Hello Mike,
>
> Just below the above text one can find the following additional
> requirement in SBC-4:
> <quote>
> 4) if the compare operation does not indicate a match, then terminate
> the command with CHECK CONDITION status with the sense key set to
> MISCOMPARE and the additional sense code set to MISCOMPARE DURING
> VERIFY OPERATION. In the sense data (see 4.18 and SPC-4) the offset
> from the start of the Data-Out Buffer to the first byte of data that
> was not equal shall be reported in the INFORMATION field.
> </quote>
>
> What I'm wondering now is how requirement (4) can be supported if
> REQ_CMP_AND_WRITE doesn't return the offset of the first byte that
> didn't match ? Additionally, shouldn't compare_and_write_callback() be
> fixed such that it returns the miscompare offset to its caller ?
>
Yeah, Hannes pointed out that the original LIO code did not support
this. For the original code, I will fix that in another patchset to keep
this one smaller and focused. For what I need, I have been trying to
think of a nice way to pass additional info around. I think the options are:
1. Instead of making it bio/request based, make it a
request_queue->compare_and_write function. We then just stack them and
can add whatever arguments/return values are necessary and do not have
to mess with the bio/request structs and function chains.
2. Add another argument to the end io functions that can be used to pass
back bio/request type specific info.
next prev parent reply other threads:[~2014-10-18 20:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-16 5:37 [PATCH 0/5] block/scsi/lio support for COMPARE_AND_WRITE michaelc
2014-10-16 5:37 ` [PATCH 1/5] block: set the nr of sectors a dev can compare and write atomically michaelc
2014-10-16 5:37 ` [PATCH 2/5] block: add function to issue compare and write michaelc
2014-10-17 9:55 ` Christoph Hellwig
2014-10-17 23:38 ` Martin K. Petersen
2014-10-18 15:16 ` Christoph Hellwig
2014-10-16 5:37 ` [PATCH 3/5] scsi: add support for COMPARE_AND_WRITE michaelc
2014-12-18 0:23 ` Elliott, Robert (Server Storage)
2014-10-16 5:37 ` [PATCH 4/5] lio: use REQ_COMPARE_AND_WRITE if supported michaelc
2014-10-16 5:37 ` [PATCH 5/5] lio iblock: add support for REQ_CMP_AND_WRITE michaelc
2014-10-16 10:39 ` [PATCH 0/5] block/scsi/lio support for COMPARE_AND_WRITE Douglas Gilbert
2014-10-16 20:01 ` Douglas Gilbert
2014-10-16 20:12 ` Elliott, Robert (Server Storage)
2014-10-17 6:02 ` Hannes Reinecke
2014-10-18 8:11 ` Bart Van Assche
2014-10-18 20:32 ` Mike Christie [this message]
2014-10-20 7:18 ` Sagi Grimberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5442CE4C.9090301@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=Elliott@hp.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=ceph-devel@vger.kernel.org \
--cc=dgilbert@interlog.com \
--cc=hare@suse.de \
--cc=linux-scsi@vger.kernel.org \
--cc=target-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.