All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
	Kevin Wolf <kwolf@redhat.com>, Jeff Cody <jcody@redhat.com>,
	Fam Zheng <famz@redhat.com>
Subject: [Qemu-devel] [PATCH for-2.6 0/2] block/mirror: Fix mirroring with guest I/O load
Date: Wed, 20 Apr 2016 00:59:46 +0200	[thread overview]
Message-ID: <1461106788-14285-1-git-send-email-mreitz@redhat.com> (raw)

Bug report: https://bugs.launchpad.net/qemu/+bug/1570134

If you are doing a mirror operation (I just tested with block-commit on
the active layer, but I guess any mirroring will do) while the guest has
rather heavy I/O load (or light I/O also, you just need to be more
unlucky) will lead to the cache of mirror's bitmap iterator becoming
stale and not reflect all dirty bits which are set in the drive's dirty
bitmap.

Generally, this isn't bad because we just restart over once we are
through, and this will refresh the iterator's cache.

But it is bad for the code which tries to find a contiguous range of
dirty chunks. This code needs to clear the bits in the iterator, so it
invokes hbitmap_iter_next() for every contiguous dirty chunk found. But
then it has to make sure that this actually cleared that chunk's dirty
bit: And if the iterator's cache is stale, this may not be the case.
Then, we run into a failed assertion.

But detecting this discrepancy is easy and refreshing the iterator's
cache is too; and then, the assertion holds.

Besides this (patch 2), the code which is supposed to wait for
overlapping in-flight requests on the first chunk of a dirty range is
dead. I didn't produce any problems regarding that, but I'm sure it's
not good. Patch 1 fixes that.


Max Reitz (2):
  block/mirror: Revive dead yielding code
  block/mirror: Refresh stale bitmap iterator cache

 block/mirror.c | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

-- 
2.8.0

             reply	other threads:[~2016-04-19 23:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-19 22:59 Max Reitz [this message]
2016-04-19 22:59 ` [Qemu-devel] [PATCH for-2.6 1/2] block/mirror: Revive dead yielding code Max Reitz
2016-04-20  5:47   ` Fam Zheng
2016-04-20 12:15   ` Kevin Wolf
2016-04-19 22:59 ` [Qemu-devel] [PATCH for-2.6 2/2] block/mirror: Refresh stale bitmap iterator cache Max Reitz
2016-04-20  8:19   ` Fam Zheng
2016-04-20 12:13   ` Kevin Wolf
2016-04-20 12:51     ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2016-04-20 12:51 ` [Qemu-devel] [PATCH for-2.6 0/2] block/mirror: Fix mirroring with guest I/O load 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=1461106788-14285-1-git-send-email-mreitz@redhat.com \
    --to=mreitz@redhat.com \
    --cc=famz@redhat.com \
    --cc=jcody@redhat.com \
    --cc=kwolf@redhat.com \
    --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.