[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] Question: any suggestions about zero-fille
From: |
Max Reitz |
Subject: |
Re: [Qemu-devel] [Qemu-block] Question: any suggestions about zero-filled image grow of raw format files ? |
Date: |
Wed, 18 Jan 2017 18:05:49 +0100 |
User-agent: |
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
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
signature.asc
Description: OpenPGP digital signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-devel] [Qemu-block] Question: any suggestions about zero-filled image grow of raw format files ?,
Max Reitz <=