[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] Question: any suggestions about zero-fille
Re: [Qemu-devel] [Qemu-block] Question: any suggestions about zero-filled image grow of raw format files ?
Wed, 18 Jan 2017 18:05:49 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
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
> 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
(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
(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.
Description: OpenPGP digital signature
|[Prev in Thread]
||[Next in Thread]|
- Re: [Qemu-devel] [Qemu-block] Question: any suggestions about zero-filled image grow of raw format files ?,
Max Reitz <=