On Wed, 2011-11-16 at 07:29 +0100, Sven Lüder wrote:
> Hallo Nicholas,
>
> it seems as if the following change on the ESXi side reverts back to pre-5.0 ESXi behaviour:
>
>
> esxcli system settings advanced set --int-value 0 --option /DataMover/HardwareAcceleratedInit (the setting gets active immediately, no reboot needed)
>
>
> Unfortunately this is a global setting for the ESXi host, which disables the use of hardware-assisted disk I/O acceleration.
> Therefore this setting might be a solution for home-brewed ESXi environments (like mine), but not for professional deployments.
>
> Anyway I would like to follow-up this topic on the LIO target side.
> Can you tell me about your thoughts/plans to get this topic resolved ?
Hello Sven,
Thanks for the follow up on this. If there is a method w/ ESXi v5.0
to disable WRITE_SAME w/ UNMAP=0 per LUN context context w/o the global
usage mentioned above for per node operation, the block limits vpd page
in target_emulate_evpd_b0() would still likely be a signal for
accelerated usage for the block zeroing primative. I'm starting to
wonder if leaving out block_limits all together from INQUIRY vpd page is
enough to invoke HardwareAcceleratedInit=0 on a per ESXi client LUN
context..?
Here is a small patch to return exception status for block limits vpd
page when emulate_tpu and emulate_tpws have both been disabled for the
device backend..
diff --git a/drivers/target/target_core_cdb.c b/drivers/target/target_core_cdb.c
index 577cc61..ca0ec13 100644
--- a/drivers/target/target_core_cdb.c
+++ b/drivers/target/target_core_cdb.c
@@ -504,6 +504,12 @@ target_emulate_evpd_b0(struct se_cmd *cmd, unsigned char *buf)
if (dev->se_sub_dev->se_dev_attrib.emulate_tpu || dev->se_sub_dev->se_dev_attrib.emulate_tpws)
have_tp = 1;
+ if (!have_tp) {
+ pr_warn("Returning TCM_UNSUPPORTED_SCSI_OPCODE for have_tp=0\n");
+ cmd->scsi_sense_reason = TCM_UNSUPPORTED_SCSI_OPCODE;
+ return -EINVAL;
+ }
+
if (cmd->data_length < (0x10 + 4)) {
pr_debug("Received data_length: %u"
" too small for EVPD 0xb0\n",
So aside from a possible workaround to fall back on a per LUN context,
we do need to consider how best to generate zeroed write payloads. The
current options to do this are generically with WRITEs using target
core, or by add block zeroing logic directly into block level discard
with IBLOCK backends. I'm still leaning towards the former as a proper
way to address this primitive.
--nab
--
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
