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

[Alexandre DERUMIER]

>>* 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.bumiller at proxmox.com>
À: "aderumier" <aderumier at odiso.com>
Cc: "pve-devel" <pve-devel at 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" <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 
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.