<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 17, 2016 at 10:00 PM, Richard W.M. Jones <span dir="ltr"><<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, May 17, 2016 at 09:50:07PM +0300, Nir Soffer wrote:<br>
> On Tue, May 17, 2016 at 7:14 PM, Shmuel Melamud <<a href="mailto:smelamud@redhat.com">smelamud@redhat.com</a>> wrote:<br>
><br>
> > Hi!<br>
> ><br>
> > There is an RFE being implemented currently (<br>
> > <a href="https://bugzilla.redhat.com/show_bug.cgi?id=734120" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=734120</a>) to use --inplace<br>
> > option in virt-sparsify to sparsify a disk image in-place, without copying<br>
> > it.<br>
> ><br>
> > The problem is that in-place sparsify works on NFS only starting from NFS<br>
> > 4.2, while the copying implementation supposedly works with any storage.<br>
> ><br>
> > From my point of view, it is better to remove the old code and start with<br>
> > the new code that uses --inplace and just add to document that one will<br>
> > need NFS >= 4.2 for sparsify feature to work. Although the old<br>
> > implementation exists, it is not used currently so there are no actual<br>
> > users that may be affected by the change. If it will be a crying need to<br>
> > use sparsify on older NFS or some other incompatible storage, we can add it<br>
> > later on the base of the new code. The old code is far from ideal and we<br>
> > will need to rewrite it in any case, and there is not sense to do this<br>
> > without real need.<br>
> ><br>
><br>
> Richard,<br>
><br>
> Currently vdsm is using:<br>
><br>
> virt-sparsify --tmp prebuilt:tmp_vol --format src_format --convert<br>
> dst_format src_vol dst_vol<br>
<br>
> (--format and --dst_format are optional)<br>
><br>
> tmp_vol, src_vol, and dst_vol can be either file on nfs/glusterfs/other<br>
> posix shared filesystem,<br>
> or an lv created on top of lun (iscsi/fc).<br>
><br>
> can you confirm this method works on all the storage types I mentioned? or<br>
> this depends<br>
> on the underlying storage server?<br>
<br>
</div></div>Copying mode requires that the dst_vol supports sparseness. The most<br>
common case where this would *not* be true is partitions on local hard<br>
disks. You can't make a partition and/or local hard disk sparse.<br>
<br>
However all of the ones you've mentioned above support sparseness, so<br>
you should be good.<br>
<br>
*If* you were using --inplace only, you could nuke the --tmp option,<br>
and indeed all the code associated with "prebuilt" qcow2 files for<br>
scratch space.<br>
<br>
That's because --inplace mode uses hardly any temporary storage, so<br>
you can just have it use regular /var/tmp or $TMPDIR.<br>
<br>
However ...<br>
<span class=""><br>
> The new inplace method is much nicer, but something that works only on<br>
> latest NFS version<br>
> is not useful for our most important users, using block storage.<br>
<br>
</span>... it's a shame, but yes.<br>
<br>
Rich.<br></blockquote><div><br></div><div>Thanks Richard!</div><div><br></div><div>So we have existing code supporting al storage types, and can benefit</div><div>our most important users.</div><div><br></div><div>We can use the new much simpler method if a user is using NFS 4.2</div><div>but it is not a replacement.</div><div><br></div><div>So I would keep the current implementation in vdsm, and add a new much </div><div>simpler implementation for inplace sparsify.</div><div><br></div><div>We should implement the missing part on the engine side, managing </div><div>the entire flow.</div><div><br></div><div>Thoughts?</div><div><br></div><div>Nir</div><div><br></div></div></div></div>