<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 21 August 2015 at 08:28, Michael Rasmussen <span dir="ltr"><<a href="mailto:mir@miras.org" target="_blank">mir@miras.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2kw" class="a3s" style="overflow:hidden">Could it be a result of the chosen filesystem in the client?<br>
What filesystem is used in the client?<br></div></blockquote><div><br><br></div><div>NTFS - but I wouldn't have thought that mattered, I don't think the move interprets the filesystem, its just a byte copy of the disk image.<br><br></div><div>Actually for my tests it was an uninitialized virtual disk.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2kw" class="a3s" style="overflow:hidden">
<span class=""><br>
> However - did you try this with compression set to "off"? because to me<br>
> from your results it looks like what your seeing is the effects of disk<br>
> compression, not thin provisioning.<br>
><br>
</span>It couldn't be compression because when I moved the disk to a raw image<br>
on NFS the actual size of the image was reported by qemu-img info to be<br>
almost the same size as what was reported from zfs get written (11GB<br>
compared tom 12,4GB).<br>
<span class=""></span></div></blockquote></div><br><br></div><div class="gmail_extra">How do you use qemu-img to check an nfsdisk? they are not visible on the host filesystem.<br><br></div><div class="gmail_extra">Your compression ration is 1.58, which is close to exactly what is needed to reduce a 20G disk to 12.4G, as reported by your zfs get all.<br></div><div class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature">Lindsay</div>
</div></div>