From: Max Reitz <mreitz@redhat.com>
To: qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
John Snow <jsnow@redhat.com>,
qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: [Qemu-devel] [PATCH v2 for-4.1 0/2] backup: Copy only dirty areas
Date: Thu, 1 Aug 2019 19:38:58 +0200 [thread overview]
Message-ID: <20190801173900.23851-1-mreitz@redhat.com> (raw)
Hi,
In a discussion with Vladimir today, we noticed that the backup job
currently is pretty broken when using copy offloading. I don’t know
about you, but my local filesystem (XFS) supports copy offloading, so
the job uses it automatically. That means, that backup is broken and
has been broken for a year on my local FS.
The last working version was 2.12, so this isn’t a regression in 4.1.
We could thus justify moving it to 4.2. But I think this should really
go into 4.1, because this is not really an edge case and as far as I
know users cannot do anything to prevent the backup job from performing
copy offloading if the system and all involved block drivers support it.
I just wonder why nobody has noticed...
v2:
- Test case: Use auto-dismiss=False for the backup jobs and explicitly
dismiss them, so we know for sure that the reference and destination
images are no longer in use by qemu by the time we want to compare
them (reported by Vladimir)
git-backport-diff against v1:
Key:
[----] : patches are identical
[####] : number of functional differences between upstream/downstream patch
[down] : patch is downstream-only
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively
001/2:[----] [--] 'backup: Copy only dirty areas'
002/2:[0009] [FC] 'iotests: Test backup job with two guest writes'
Max Reitz (2):
backup: Copy only dirty areas
iotests: Test backup job with two guest writes
block/backup.c | 13 +++++++++++--
tests/qemu-iotests/056 | 39 ++++++++++++++++++++++++++++++++++++++
tests/qemu-iotests/056.out | 4 ++--
3 files changed, 52 insertions(+), 4 deletions(-)
--
2.21.0
next reply other threads:[~2019-08-01 17:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-01 17:38 Max Reitz [this message]
2019-08-01 17:38 ` [Qemu-devel] [PATCH v2 for-4.1 1/2] backup: Copy only dirty areas Max Reitz
2019-08-01 17:39 ` [Qemu-devel] [PATCH v2 for-4.1 2/2] iotests: Test backup job with two guest writes Max Reitz
2019-08-01 18:02 ` Vladimir Sementsov-Ogievskiy
2019-08-01 23:36 ` [Qemu-devel] [PATCH v2 for-4.1 0/2] backup: Copy only dirty areas no-reply
2019-08-02 13:34 ` Kevin Wolf
2019-08-02 13:50 ` Max Reitz
2019-08-05 15:36 ` Max Reitz
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=20190801173900.23851-1-mreitz@redhat.com \
--to=mreitz@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--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.