All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Stefan Reiter <s.reiter@proxmox.com>, qemu-block@nongnu.org
Cc: kwolf@redhat.com, vsementsov@virtuozzo.com, qemu-devel@nongnu.org
Subject: Re: [PATCH for-5.1 v2 1/2] block/block-copy: always align copied region to cluster size
Date: Mon, 10 Aug 2020 17:15:26 +0200	[thread overview]
Message-ID: <8fd06678-0f68-0cfc-b15a-c793f8f231cd@redhat.com> (raw)
In-Reply-To: <20200810095523.15071-1-s.reiter@proxmox.com>


[-- Attachment #1.1: Type: text/plain, Size: 1463 bytes --]

On 10.08.20 11:55, Stefan Reiter wrote:
> Since commit 42ac214406e0 (block/block-copy: refactor task creation)
> block_copy_task_create calculates the area to be copied via
> bdrv_dirty_bitmap_next_dirty_area, but that can return an unaligned byte
> count if the image's last cluster end is not aligned to the bitmap's
> granularity.
> 
> Always ALIGN_UP the resulting bytes value to satisfy block_copy_do_copy,
> which requires the 'bytes' parameter to be aligned to cluster size.
> 
> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
> ---
> 
> I've now marked it for-5.1 since it is just a fix, but it's probably okay if
> done later as well.

42ac214406e0 wasn’t in 5.0, so this would be a regression if we don’t
get it in 5.1.  I suppose this is an edge case, because most images
should be aligned to the cluster size, but I think objectively this is
something for 5.1.

So I’ll apply this series to my block branch:

https://git.xanclic.moe/XanClic/qemu/commits/branch/block

And I think I’m going to send a pull request tomorrow morning.  I see
there’s another patch for 5.1 on the list, so it should be OK.

If you want me to act on any of the suggestions I gave on your test,
feel free to say so and I’ll handle those that make sense to you (like,
I hope the s/4097/4096/ thing perhaps).

Thanks for finding and fixing this!

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      parent reply	other threads:[~2020-08-10 15:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-10  9:55 [PATCH for-5.1 v2 1/2] block/block-copy: always align copied region to cluster size Stefan Reiter
2020-08-10  9:55 ` [PATCH for-5.1 v2 2/2] iotests: add test for unaligned granularity bitmap backup Stefan Reiter
2020-08-10 15:11   ` Max Reitz
2020-08-10 15:35     ` Stefan Reiter
2020-08-10 15:15 ` Max Reitz [this message]

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=8fd06678-0f68-0cfc-b15a-c793f8f231cd@redhat.com \
    --to=mreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=s.reiter@proxmox.com \
    --cc=vsementsov@virtuozzo.com \
    /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.