On Sun, Oct 20, 2013 at 6:34 PM, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > On Sat, 12 Oct 2013 07:38:59 -0700 > Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx> 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@xxxxxxxxx> >> --- >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
