On Tue, May 17, 2016 at 10:00 PM, Richard W.M. Jones <rjo...@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 <smela...@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
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel