qemu-devel
[Top][All Lists]
Advanced

[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: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH V5] qemu-img: align result of is_allocated_sectors
Date: Wed, 11 Jul 2018 10:25:26 +0200
User-agent: Mutt/1.9.1 (2017-09-22)

Am 10.07.2018 um 22:16 hat Peter Lieven geschrieben:
> 
> 
> > 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?

Right, I noticed only after sending this email that it's qemu-img map
output that changes and this might actually be okay. I didn't check,
however, if the exact changes are what is expected and whether we need
to add more test cases to cover what the test originally wanted to
cover.

So after all, there's a good chance that all that's missing is just an
update to the test case.

Kevin



reply via email to

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