Re: [Qemu-devel] [PATCH v1 00/13] qcow2: space preallocation and COW improvements

[Denis V. Lunev]

On 05/23/2017 05:35 PM, Eric Blake wrote:
> On 05/19/2017 04:34 AM, Anton Nefedov wrote:
>> This pull request is to address a few performance problems of qcow2 format:
>>
>>   1. non cluster-aligned write requests (to unallocated clusters) explicitly
>>     pad data with zeroes if there is no backing data. This can be avoided
>>     and the whole clusters are preallocated and zeroed in a single
>>     efficient write_zeroes() operation, also providing better host file
>>     continuity
>>
>>   2. moreover, efficient write_zeroes() operation can be used to preallocate
>>     space megabytes ahead which gives noticeable improvement on some storage
>>     types (e.g. distributed storages where space allocation operation is
>>     expensive)
>>
>>   3. preallocating/zeroing the clusters in advance makes possible to enable
>>     simultaneous writes to the same unallocated cluster, which is beneficial
>>     for parallel sequential write operations which are not cluster-aligned
>>
>> Performance test results are added to commit messages (see patch 3, 12)
> And now Berto has posted parallel patches. I'm not sure which ones to
> focus on, or if you can work it out between you on the best approach
> forward...
>
> https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg05236.html
>
I have seen those patches and will comment.

yes, they are intersect. He is concentrating on the fact of performing
operation in minimal read/write amount. We have made an attempt
to minimize amount of IO in the expand case.

Frankly speaking Berto patches are not that influenced. We definitely
should merge IO if write_zeroes are impossible. Thus both could
be merged in parallel.

What I want to note is the fact that there is another big problem
in QCOW2 layer. We have 64k block by default. Guest request
can be 4-5Mb in total. If the image is fragmented, most like
it will if it is old, we will have sequentially read/write the data.
Thus in ideal world we should switch to co-routine pool and the
same approach would be the best in COW too.

Pls note, that this also would very positively influence VM downtime
on migration as bdrv_drain_all is one the most important time hogs.

Den