[ovirt-devel] In-place sparsify support in VDSM

[Nir Soffer]

On Tue, May 17, 2016 at 10:00 PM, Richard W.M. Jones <rjones at redhat.com>
wrote:

> On Tue, May 17, 2016 at 09:50:07PM +0300, Nir Soffer wrote:
> > On Tue, May 17, 2016 at 7:14 PM, Shmuel Melamud <smelamud at redhat.com>
> wrote:
> >
> > > Hi!
> > >
> > > There is an RFE being implemented currently (
> > > https://bugzilla.redhat.com/show_bug.cgi?id=734120) to use --inplace
> > > option in virt-sparsify to sparsify a disk image in-place, without
> copying
> > > it.
> > >
> > > The problem is that in-place sparsify works on NFS only starting from
> NFS
> > > 4.2, while the copying implementation supposedly works with any
> storage.
> > >
> > > From my point of view, it is better to remove the old code and start
> with
> > > the new code that uses --inplace and just add to document that one will
> > > need NFS >= 4.2 for sparsify feature to work. Although the old
> > > implementation exists, it is not used currently so there are no actual
> > > users that may be affected by the change. If it will be a crying need
> to
> > > use sparsify on older NFS or some other incompatible storage, we can
> add it
> > > later on the base of the new code. The old code is far from ideal and
> we
> > > will need to rewrite it in any case, and there is not sense to do this
> > > without real need.
> > >
> >
> > Richard,
> >
> > Currently vdsm is using:
> >
> >     virt-sparsify --tmp prebuilt:tmp_vol --format src_format --convert
> > dst_format src_vol dst_vol
>
> > (--format and --dst_format are optional)
> >
> > tmp_vol, src_vol, and dst_vol can be either file on nfs/glusterfs/other
> > posix shared filesystem,
> > or an lv created on top of lun (iscsi/fc).
> >
> > can you confirm this method works on all the storage types I mentioned?
> or
> > this depends
> > on the underlying storage server?
>
> Copying mode requires that the dst_vol supports sparseness.  The most
> common case where this would *not* be true is partitions on local hard
> disks.  You can't make a partition and/or local hard disk sparse.
>
> However all of the ones you've mentioned above support sparseness, so
> you should be good.
>
> *If* you were using --inplace only, you could nuke the --tmp option,
> and indeed all the code associated with "prebuilt" qcow2 files for
> scratch space.
>
> That's because --inplace mode uses hardly any temporary storage, so
> you can just have it use regular /var/tmp or $TMPDIR.
>
> However ...
>
> > The new inplace method is much nicer, but something that works only on
> > latest NFS version
> > is not useful for our most important users, using block storage.
>
> ... it's a shame, but yes.
>
> Rich.
>

Thanks Richard!

So we have existing code supporting al storage types, and can benefit
our most important users.

We can use the new much simpler method if a user is using NFS 4.2
but it is not a replacement.

So I would keep the current implementation in vdsm, and add a new much
simpler implementation for inplace sparsify.

We should implement the missing part on the engine side, managing
the entire flow.

Thoughts?

Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160517/c3673812/attachment-0001.html>