`<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 26, 2015 at 1:05 PM, Dan McDonald <span dir="ltr"><<a href="mailto:danmcd@omniti.com" target="_blank">danmcd@omniti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
</span>WRITE_SAME is one of the four VAAI primitives. Nexenta wrote this code for NS, and upstreamed two of them:<br>
<br>
WRITE_SAME is "hardware assisted erase".<br>
<br>
UNMAP is "hardware assisted freeing".<br>
<br>
Those are in upstream illumos.<br>
<br>
ATS is atomic-test-and-set or "hardware assisted fine-grained locking".<br>
<br>
XCOPY is "hardware assisted copying".<br>
<br>
These are in NexentaStor, and after being held back, were open-sourced, but not yet upstreamed.<br>
<span class=""></span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""> <br></span></blockquote></div><br></div><div class="gmail_extra">Ahh, VAAI. I suspect this is a bigger bite to chew, looking back at some prior discussions on this list (although I'm sure many are anxiously awaiting this to be upstreamed). I'm guessing Microsoft's ODX will also be supported since I understand that is just an XCOPY. I see that FreeNAS now has support for both VAAI and ODX - are they porting stuff from the various Illumos distros (including the referenced Nexenta work on VAAI or is it their own implementation)?</div><div class="gmail_extra"><br></div><div class="gmail_extra">After some more reading to answer my own questions, I came across this VMware blog post (<a href="http://blogs.vmware.com/vsphere/2012/06/low-level-vaai-behaviour.html">http://blogs.vmware.com/vsphere/2012/06/low-level-vaai-behaviour.html</a>):</div><div class="gmail_extra"><br></div><div class="gmail_extra">"The following provisioning tasks are accelerated by the use of the WRITE SAME command:</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cloning operations for eagerzeroedthick target disks.</div><div class="gmail_extra">Allocating new file blocks for thin provisioned virtual disks.</div><div class="gmail_extra">Initializing previous unwritten file blocks for zerothick virtual disks."</div><div class="gmail_extra"><br></div><div class="gmail_extra">I don't seem to have issues allocating smaller amounts of space, so I suspect that using thin or lazy zero will work.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Secondly, it *might* just be the vSphere fat client, as I found another VMware KB (<a href="http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2058287">http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2058287</a>) which states I cannot make a disk larger than 4TB, which contradicts this properties dialog:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="http://i.imgur.com/f9liqpR.png">http://i.imgur.com/f9liqpR.png</a><br></div><div class="gmail_extra">(says maximum file size of 2TB in vSphere fat client)</div><div class="gmail_extra"><br></div><div class="gmail_extra">versus:</div><div class="gmail_extra"><a href="http://i.imgur.com/6Ya3oH4.png">http://i.imgur.com/6Ya3oH4.png</a><br></div><div class="gmail_extra">(says maximum file size 64TB in the vSphere web client)</div><div class="gmail_extra"><br></div><div class="gmail_extra">The KB goes on to state, "Checking the size of the newly created or expanded VMDK, you find that it is 4 TB." is untrue, because it allocated and is using 10TB. Don't know how much to trust that info as it seems contradictory. Still, it shouldn't cause the kernel panic like it did.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thirdly, it appears I can disable any of the VAAI primitives in the host configuration, if all else fails (since we've determined that it is likely caused by WRITE_SAME). Good read on this via the VAAI FAQ here (which shows you how to check the properties via the ESX CLI): </div><div class="gmail_extra"><a href="http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1021976">http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1021976</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">So here's what I will attempt to test:</div><div class="gmail_extra">- Create thin vmdk @ 10TB with vSphere fat client </div><div class="gmail_extra">- Create lazy zeroed vmdk @ 10 TB with vSphere fat client</div><div class="gmail_extra">- Create eager zeroed vmdk @ 10 TB with vSphere web client</div><div class="gmail_extra"><div class="gmail_extra">- Create thin vmdk @ 10TB with vSphere web client</div><div class="gmail_extra">- Create lazy zeroed vmdk @ 10 TB with vSphere web client</div><div class="gmail_extra"><br></div><div class="gmail_extra">So it seems I do have alternatives (disabling DataMover.HardwareAcceleratedMove as a last resort).</div></div></div>
`