From: Kevin Wolf <kwolf@redhat.com>
To: Peter Lieven <pl@kamp.de>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH V5] qemu-img: align result of is_allocated_sectors
Date: Wed, 11 Jul 2018 10:25:26 +0200 [thread overview]
Message-ID: <20180711082526.GA4266@localhost.localdomain> (raw)
In-Reply-To: <73DCB217-9027-4248-8C81-A83AD4512927@kamp.de>
Am 10.07.2018 um 22:16 hat Peter Lieven geschrieben:
>
>
> > Am 10.07.2018 um 17:31 schrieb Kevin Wolf <kwolf@redhat.com>:
> >
> > 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 <pl@kamp.de>
> >
> > 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
next prev parent reply other threads:[~2018-07-11 8:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-10 15:05 [Qemu-devel] [PATCH V5] qemu-img: align result of is_allocated_sectors Peter Lieven
2018-07-10 15:31 ` Kevin Wolf
2018-07-10 20:16 ` Peter Lieven
2018-07-11 8:25 ` Kevin Wolf [this message]
2018-07-12 9:23 ` Peter Lieven
2018-07-12 9:26 ` Peter Lieven
2018-07-12 11:41 ` Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180711082526.GA4266@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pl@kamp.de \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.