>>* From lvm thin to qcow2: >>Since lvm-thin doesn't catch SEEK_DATA/SEEK_HOLE it'll consider the >>entire device as being allocated and reaches the slow path for detectin >>zeroes, this part should still work however and the qcow2 file should be >>smaller.
I'm not sure here, because when I convert a source nfs raw file to ceph rbd, it's full allocated. (because nfs (< 4.2) don't support seek_hole) ----- Mail original ----- De: "Wolfgang Bumiller" <w.bumil...@proxmox.com> À: "aderumier" <aderum...@odiso.com> Cc: "pve-devel" <pve-devel@pve.proxmox.com> Envoyé: Jeudi 28 Juillet 2016 09:46:00 Objet: Re: [pve-devel] Sparse clone/move over a thin LVM ? On Thu, Jul 28, 2016 at 07:20:21AM +0200, Alexandre DERUMIER wrote: > also wolfgang has added his zeroinit filter to qemu-img command some time > ago, > so it should work. Like mentioned in another thread it doesn't cover 100% of the use cases, but should cover qcow2=>thin. (...) > > ----- Mail original ----- > De: "aderumier" <aderum...@odiso.com> > À: "dietmar" <diet...@proxmox.com>, "pve-devel" <pve-devel@pve.proxmox.com> > Envoyé: Jeudi 28 Juillet 2016 06:52:39 > Objet: Re: [pve-devel] Sparse clone/move over a thin LVM ? > > >>Why not fix qemu-img instead? > > This is strange, I am pretty sure that qemu-img was skipping zero writes > > > " '-S' indicates the consecutive number of bytes (defaults to 4k) that > must\n" > " contain only zeros for qemu-img to create a sparse image during\n" > " conversion. If the number of bytes is 0, the source will not be scanned > for\n" > " unallocated or zero sectors, and the destination image will always be\n" > " fully allocated\n" > > it should be sparse by default, until we setup "-S 0" * From qcow2 to lvm thin: It'll detect zeroes coming from the source via qcow2's metadata, this part works and makes it call blk_write_zeroes(). This calls the BlockDriver's bdrv_co_write_zeroes, which for devices ends up with a BLKZEROOUT ioctl(), which lvm-thin does not have a special case for so it literally zeroes out the entire devices. This is where the zeroinit filter kicks in: if the LV was just created and is thus not fully allocated it'll turn all file-extending zero-writes into seeks. * From lvm thin to qcow2: Since lvm-thin doesn't catch SEEK_DATA/SEEK_HOLE it'll consider the entire device as being allocated and reaches the slow path for detectin zeroes, this part should still work however and the qcow2 file should be smaller. _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
