Hello Nicholas,
is there any follow-up regarding the WRITE SAME support required by
ESXi 5? Although it is possible to globally disable hardware I/O
acceleration on ESXi hosts, this is not a solution if we want to
use LIO and enterprise arrays in the same environment.
Yesterday, I played with ESXi 5 for a while and tried a workaround that
seems to fix it. If transport_generic_cmd_sequencer() returns sense
reason TCM_UNSUPPORTED_SCSI_OPCODE instead of TCM_INVALID_CDB_FIELD,
ESXi sends WRITE SAME only once and then (probably) falls back to
non-accelerated block zeroing. The patch is below. Unfortunately I've
found no relevant VMware docs about hardware acceleration requirements
in ESXi 5, except for the general announcements that ESXi 5 uses
standardized T10 versions of WRITE SAME, XCOPY and COMPARE AND WRITE.
So I still don't know if this is the right way to tell ESXi initiator
that we don't support block zeroing offload.
Best regards
Martin
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -2665,7 +2665,7 @@ static int transport_generic_cmd_sequencer(
cmd->se_cmd_flags |= SCF_SCSI_CONTROL_SG_IO_CDB;
if (target_check_write_same_discard(&cdb[10], dev) < 0)
- goto out_invalid_cdb_field;
+ goto out_unsupported_cdb;
if (!passthrough)
cmd->execute_task = target_emulate_write_same;
break;
@@ -2948,7 +2948,7 @@ static int transport_generic_cmd_sequencer(
cmd->se_cmd_flags |= SCF_SCSI_CONTROL_SG_IO_CDB;
if (target_check_write_same_discard(&cdb[1], dev) < 0)
- goto out_invalid_cdb_field;
+ goto out_unsupported_cdb;
if (!passthrough)
cmd->execute_task = target_emulate_write_same;
break;
@@ -2971,7 +2971,7 @@ static int transport_generic_cmd_sequencer(
* of byte 1 bit 3 UNMAP instead of original reserved field
*/
if (target_check_write_same_discard(&cdb[1], dev) < 0)
- goto out_invalid_cdb_field;
+ goto out_unsupported_cdb;
if (!passthrough)
cmd->execute_task = target_emulate_write_same;
break;
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
