[pve-devel] Sparse clone/move over a thin LVM ?

Wolfgang Bumiller w.bumiller at proxmox.com
Thu Jul 28 09:46:00 CEST 2016

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" <aderumier at odiso.com>
> À: "dietmar" <dietmar at proxmox.com>, "pve-devel" <pve-devel at 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

* 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

More information about the pve-devel mailing list