Re: [Qemu-devel] [Qemu-block] Question: any suggestions about zero-filled image grow of raw format files ?

Re: [Qemu-devel] [Qemu-block] Question: any suggestions about zero-filled image grow of raw format files ?

[Max Reitz]

[-- Attachment #1: Type: text/plain, Size: 2803 bytes --]

On 16.01.2017 07:20, fuweiwei (C) wrote:
> Dear all:
> 
>  
> 
> I have a question. In qemu-kvm platforms, raw format virtual images have
> several preallocation options,
> 
> such as thin (sparse, no preallocation), falloc and full (zero-filled
> preallocation). However, if one resize
> 
> a full-allocated image to a larger volume, the additional part of the
> image is thin-allocated. This may
> 
> introduce some diskspace management problems.

Adding something like preallocation=full would probably not be too
difficult, because qemu-img can just fill the space itself.

But adding preallocation=falloc for resize would probably require some
yet missing infrastructure in qemu. Currently, bdrv_truncate() is just a
function that takes the new size as an option and that's it.

> So I wonder if we could introduce zero-filled image grow (resize) for
> raw images. For offline image grow,
> 
> could we add addition options (-p) to specify the preallocation method
> for the additional part of image,
> 
> just like image creation:
> 
>  
> 
> qemu-img resize -f raw test.img [-p full] +1G
> 
>  
> 
> this will fill zeroes in the range of [original size, original size +
> 1G] in the file.

Well, for raw images you can just use fallocate afterwards manually; or,
if you want full preallocation, that shouldn't be too difficult to
implement.

> Online zero-filled image grow is the primary problem, because filling
> zeroes is time-consuming while
> 
> qmp_block_resize is a synchronized function, which may block the qemu
> main process. Is there any solutions?

The thing that comes to mind is doing the resize and then writing zeroes
in the guest.

Another thing that I can imagine, but which is probably strongly
disadvisable (because of several reasons of which I can only imagine a
few right now), is:

(0) modify the null block driver so that it can return BDRV_BLOCK_DATA
from null_co_get_block_status()

(1) resize the volume using block_resize; let size_old be the old size
and size_new be the new size
(2) blockdev-add a null-co block driver with read-zeroes=true,
size=$((new_size - old_size)), and the option so that it will return
BDRV_BLOCK_DATA
(3) blockdev-add a raw block driver on top of the original volume with
offset=old_size,size=$((new_size - old_size))
(4) blockdev-mirror from the null-co node to the new raw node

And you're done.

But as I said, that is a bad hack.

Maybe it would make sense to have a dedicated write-zeroes block job
that can write a range of zeroes to some offset of a block device.

This wouldn't help you if you wanted to use fallocate, but that is again
something that would need to be implemented for bdrv_truncate() and thus
exposed over block_resize.

Max




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 512 bytes --]