qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v12 00/10] qcow2: cluster space preallocation


From: Anton Nefedov
Subject: Re: [Qemu-devel] [PATCH v12 00/10] qcow2: cluster space preallocation
Date: Thu, 21 Feb 2019 08:05:13 +0000

On 14/1/2019 2:18 PM, Anton Nefedov wrote:
> This pull request is to start to improve a few performance points of
> qcow2 format:
> 
>    1. non cluster-aligned write requests (to unallocated clusters) explicitly
>       pad data with zeroes if there is no backing data.
>       Resulting increase in ops number and potential cluster fragmentation
>       (on the host file) is already solved by:
>         ee22a9d qcow2: Merge the writing of the COW regions with the guest 
> data
>       However, in case of zero COW regions, that can be avoided at all
>       but the whole clusters are preallocated and zeroed in a single
>       efficient write_zeroes() operation
> 
>    2. moreover, efficient write_zeroes() operation can be used to preallocate
>       space megabytes (*configurable number) ahead which gives noticeable
>       improvement on some storage types (e.g. distributed storage)
>       where the space allocation operation might be expensive)
>       (Not included in this patchset since v6).
> 
>    3. this will also allow to enable simultaneous writes to the same 
> unallocated
>       cluster after the space has been allocated & zeroed but before
>       the first data is written and the cluster is linked to L2.
>       (Not included in this patchset).
> 
> Efficient write_zeroes usually implies that the blocks are not actually
> written to but only reserved and marked as zeroed by the storage.
> In this patchset, file-posix driver is marked as supporting this operation
> if it supports (/configured to support) fallocate() operation.
> 
> Existing bdrv_write_zeroes() falls back to writing zero buffers if
> write_zeroes is not supported by the driver.
> A new flag (BDRV_REQ_ALLOCATE) is introduced to avoid that but return ENOTSUP.
> Such allocate requests are also implemented to possibly overlap with the
> other requests. No wait is performed but an error returned in such case as 
> well.
> So the operation should be considered advisory and a fallback scenario still
> handled by the caller (in this case, qcow2 driver).
> 
> simple perf test:
> 
>    qemu-img create -f qcow2 test.img 4G && \
>    qemu-img bench -c $((1024*1024)) -f qcow2 -n -s 4k -t none -w test.img
> 
> test results (seconds):
> 
>      +-----------+-------+------+-------+------+------+
>      |   file    |    before    |     after    | gain |
>      +-----------+-------+------+-------+------+------+
>      |    ssd    |      61.153  |      36.313  |  41% |
>      |    hdd    |     112.676  |     122.056  |  -8% |
>      +-----------+--------------+--------------+------+
> 

ping

reply via email to

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