qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v3 0/6] qemu-img: add preallocation=full


From: Eric Blake
Subject: Re: [Qemu-devel] [RFC PATCH v3 0/6] qemu-img: add preallocation=full
Date: Fri, 20 Dec 2013 05:54:34 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 12/20/2013 03:30 AM, Stefan Hajnoczi wrote:
> On Thu, Dec 19, 2013 at 10:27:35AM +0800, Hu Tao wrote:
>> This series implements full image preallocation to create a non-sparse image
>> file at creation time, both for raw and qcow2 format. The purpose is to avoid
>> performance deterioration of the guest cause by sparse image.
> 
> I'm not sure the new bdrv_preallocate() interface is necessary.  Can
> qcow2_create() simply pass a preallocate=full option to
> bdrv_create_file()?
> 
> It's simpler if we avoid bdrv_preallocate(), just keep it a
> .bdrv_create() option.  That way we also avoid the question of how
> exactly preallocate functions on an image file that already has blocks
> allocated.
> 
> So what I imagine is:
> 1. Add preallocation=full support to raw-posix.c
> 2. Add preallocation=full support to qcow2.c, calculate image file size
> including metadata for bdrv_create_file().
> 
> CCing Eric Blake so libvirt can consider how full preallocation
> interacts with their safezero() preallocation.  If QEMU handles
> preallocation can we skip safezero()?  Is there a concern about full
> preallocation in QEMU taking a long time without progress report?

If libvirt can detect that qemu is new enough to do preallocation, then
libvirt can skip its own preallocation.  Which means you need to make
sure that QMP can probe the existence of this new feature (probably
already possible via query-command-line-options, but see also my reply
to 1/6 about starting to put this in QAPI).

The fact that preallocation is sometimes long running is definitely
worth considering; but it raises the more generic issue of how to turn
any long running blocking command into an asynchronous job that gets
started, then has both polling and event-notification progress until
completion, as well as the option of an early abort if it is taking too
long.

And there's my long-standing gripe that qemu-img doesn't support -p
progress meters for enough of its already-existing long-running
commands, which makes it harder for libvirt to provide wrappers around
qemu-img operations when manipulating images not associated with a
running VM.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]