[stgt] [PATCH] Add an array that describes which opcodes are supported by the RDWR and SHEEPDOG backends.

[ronnie sahlberg]

On Sun, Oct 20, 2013 at 6:34 PM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> On Sat, 12 Oct 2013 07:38:59 -0700
> Ronnie Sahlberg <ronniesahlberg at gmail.com> wrote:
>
>> While RDWR supports all SBC opcodes that TGTD implement SHEEPDOG
>> only supports a subset and lacks the following opcodes:
>>             WRITE_VERIFY10/12/16 VERIFY10/12/16 PREFETCH10/16
>>             WRITE_SAME10/16 UNMAP and ORWRITE
>>
>> This allows backends to specify which opcodes it is prepared to process
>> and which commands should fail with invalid op code
>> and allows SHEEPDOG backed LUNs to respond with INVALID_OP_CODE
>> correctly.
>>
>> This is most useful for block devices where we have several different backens
>> and where some backends only support a subset of the commands
>>
>> Signed-off-by: Ronnie Sahlberg <ronniesahlberg at gmail.com>
>> ---
>>  usr/bs.c          |    8 ++++++++
>>  usr/bs_rdwr.c     |   51 +++++++++++++++++++++++++++++++++++++++++++++++++++
>>  usr/bs_sheepdog.c |   38 ++++++++++++++++++++++++++++++++++++++
>>  usr/scsi.c        |    6 ++++++
>>  usr/tgtd.h        |    1 +
>>  5 files changed, 104 insertions(+), 0 deletions(-)
>
> Why backend store's bs_cmd_submit cannot return a proper error and
> sbr_rc returns that error to an initiator?


It could, but this way it is more explicit which opcodes are
available, and a simple compare of the array between opcodes
makes it easy for non-bs_rdwr backend developers to see the delta
between their backend and rdwr.

A second reason is for a followup patch.
The followup patch will use this array so that it can prune which
opcodes to report back for the REPORT_SUPPORTED_OPCODE opcode.
So that when you issue that command to a sheepdog LUN  you get a
pruned list back that only lists the opcodes that sheepdog supports.


regards
ronnie sahlberg
--
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