[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v4 0/4] qemu-img: add preallocation=full
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [RFC PATCH v4 0/4] qemu-img: add preallocation=full |
Date: |
Fri, 17 Jan 2014 17:05:36 +0800 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Dec 27, 2013 at 11:05:50AM +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.
>
> v4: - remove bdrv_preallocate and make preallocation a bdrv_create_file
> option
> - prealloc_mode -> PreallocMode and add it to QAPI
> - fix return value in raw_preallocate2
>
> Hu Tao (4):
> qapi: introduce PreallocMode
> raw,qcow2: don't convert file size to sector size
> raw-posix: Add full image preallocation option
> qcow2: Add full image preallocation option
>
> block/qcow2.c | 64
> +++++++++++++++++++++++++++++++++++++++++++++----------
> block/raw-posix.c | 50 +++++++++++++++++++++++++++++++++++++++++--
> qapi-schema.json | 12 +++++++++++
> 3 files changed, 113 insertions(+), 13 deletions(-)
I've thought more about the lack of progress information during
posix_fallocate(3). Users creating 10s or 100s of GB images may have to
wait for a long time if posix_fallocate(3) is implemented in userspace
(effectively dd if=/dev/zero of=vm.img).
But I think adding preallocate=full is a good starting point. Modern
file systems implement it efficiently so the wait time should be
negligible. If creating images takes too long we could consider a
fancier interface later.
I left comments on specific patches.