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