On Sat, 2011-10-29 at 06:38 +0200, Sven Lüder wrote:
> Dear all,
>
Greetings Sven,
> Maybe you can give me a hint on how I can proceed on this topic:
>
> I am using Vmware 5.0 connected to a LIO target hosting the (shared) vmfs
> volume.
> Whenever files are being copied or written to the vmfs volume the copy
> /write process on VMware gets hung.
> When this happens multiple messages are logged in the kernel log of the LIO
> target system:
>
> WRITE_SAME w/o UNMAP bit not supported for Block Discard Emulation
>
>
So the reason this was not initially supported is because Linux
SCSI/Block does not support WRITE_SAME w/o UNMAP / explict zeroing of
memory, which is the main function it serves in vSphere 5.
> The "Implementing EMC SYMMETRIX VIRTUAL PROVISIONING WITH VMWARE VSPHERE"
> white paper from EMC states that VMware in not setting the UNMAP bit by
> intention:
> (page 13) "It is important to note that VMware ESX/ESXi only make use of
> WRITE SAME without the unmap bit set and therefore are unable to deallocate
> blocks".
>
> So this seems to me as if LIO and VMware ESXi 5.0 are at the moment not
> interoperable with each other.
>
>
There are folks who currently support this with LIO using a special
backend device that supports explicit zeroing of memory, but as you've
noticed we currently don't support generic emulation of this command
just yet.
> Version information:
> VMWare 5.0 (patch level 474610)
> VMFS5 volume on Target LUN, 1TB LUN size
> Fedora Core Linux (Rawhide)
> Kernel 3.1.0-0.rc10.git0.1.fc17.x86_64
> iSCSI version: v4.1.0-rc1
> TCM_FC version: 3.1.0-0.rc10.git0.1.fc17.x86_64
> TCM Loopback version: v2.1-rc1
>
>
> Reproducing the issue seems to be quite easy:
> - Create a LUN and mount it on the ESXi server
> - Format the LUN with VMFS5 (this interestingly works)
> - SSH to the ESXi box and simply copy a simple file (e.g. /sbin/vmkfstools)
> to the vmfs volume
>
> Any advice would be very appreciated.
>
I believe the use of WRITE_SAME w/o UNMAP is an extra primitive that is
disabled by default. Looking at the requirements spec from VMWare, it
mentions the following:
· Report OPTIMAL TRANSFER LENGTH GRANULARITY in the B0 VPD page to
indicate WRITE SAME alignment. In the next major vSphere release,
ESX hosts will not issue zero block requests that are not aligned
according to the alignment indicated by the vendor.
So we currently report back the OPTIMAL TRANSFER LENGTH GRANULARITY
regardless if emulate_tpws=1 (write same) is enabled, which I think may
be what VMWare is using to know when to enable WRITE_SAME w/o UNMAP usage.
Unfortunately this value is currently hard-coded into target_core_cdb.c
EVPD INQUIRY emulation. The following patch will report zero for this
value when emulate_tp[ws,u]=0 are set (the default in target-core) and
should disable VMWare's usage of WRITE_SAME w/o UNMAP.
Please give this a shot on your setup, and let us know if it's enough to
disable WRITE_SAME w/o UNMAP on v3.1 code.
Thanks,
--nab
diff --git a/drivers/target/target_core_cdb.c b/drivers/target/target_core_cdb.c
index 38535eb..202f3e4 100644
--- a/drivers/target/target_core_cdb.c
+++ b/drivers/target/target_core_cdb.c
@@ -525,7 +525,8 @@ target_emulate_evpd_b0(struct se_cmd *cmd, unsigned char *buf)
/*
* Set OPTIMAL TRANSFER LENGTH GRANULARITY
*/
- put_unaligned_be16(1, &buf[6]);
+ if (have_tp)
+ put_unaligned_be16(1, &buf[6]);
/*
* Set MAXIMUM TRANSFER LENGTH
--
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
