[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH V5] qemu-img: align result of is_allocated_secto
From: |
Peter Lieven |
Subject: |
Re: [Qemu-devel] [PATCH V5] qemu-img: align result of is_allocated_sectors |
Date: |
Tue, 10 Jul 2018 22:16:47 +0200 |
> Am 10.07.2018 um 17:31 schrieb Kevin Wolf <address@hidden>:
>
> Am 10.07.2018 um 17:05 hat Peter Lieven geschrieben:
>> We currently don't enforce that the sparse segments we detect during convert
>> are
>> aligned. This leads to unnecessary and costly read-modify-write cycles either
>> internally in Qemu or in the background on the storage device as nearly all
>> modern filesystems or hardware have a 4k alignment internally.
>>
>> This patch modifies is_allocated_sectors so that its *pnum result will always
>> end at an alignment boundary. This way all requests will end at an alignment
>> boundary. The start of all requests will also be aligned as long as the
>> results
>> of get_block_status do not lead to an unaligned offset.
>>
>> The number of RMW cycles when converting an example image [1] to a raw
>> device that
>> has 4k sector size is about 4600 4k read requests to perform a total of
>> about 15000
>> write requests. With this path the additional 4600 read requests are
>> eliminated while
>> the number of total write requests stays constant.
>>
>> [1]
>> https://cloud-images.ubuntu.com/releases/16.04/release/ubuntu-16.04-server-cloudimg-amd64-disk1.vmdk
>>
>> Signed-off-by: Peter Lieven <address@hidden>
>
> It looked convincing, but I'm afraid this is still not correct.
> qemu-iotests 122 fails for me with this patch.
I will have a look, where and why exactly it fails, but the allocation pattern
might be slightly different due to the alignment. What counts is that the
output is byte identical or not?
Peter