From: "Bryan S Rosenburg" <rosnbrg@us.ibm.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: Qemu-block <qemu-block@nongnu.org>,
qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
Leo Luan <leoluan@gmail.com>, John Snow <jsnow@redhat.com>,
Qemu-devel <qemu-devel-bounces+rosnbrg=us.ibm.com@nongnu.org>
Subject: RE: Avoid copying unallocated clusters during full backup
Date: Tue, 21 Apr 2020 10:41:26 -0400 [thread overview]
Message-ID: <OF1A8659FD.3A0BC2A3-ON85258551.00504BEA-85258551.0050B28F@notes.na.collabserv.com> (raw)
In-Reply-To: <59e3fb48-b397-1e59-6f29-8e7f9148fe41@virtuozzo.com>
[-- Attachment #1: Type: text/plain, Size: 813 bytes --]
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> wrote on
04/20/2020 11:04:33 AM:
> Yes, the problem is that copy_range subsystem handles block-status,
> when generic backup copying loop doesn't. I'm not sure that adding
> fallback into copy-range is a correct thing to do, at least it
> should be optional, enabled by flag.. But you don't need it for your
problem,
> as it is already fixed upstream:
>
> You need to backport my commit 2d57511a88 "block/block-copy: use
> block_status" (together with 3 preparing patches before it, or with
> the whole series (including some refactoring after the 2d57511 commit)
Vladimir, thanks for the pointer to the "block/block-copy: use
block_status" patch set. Those 4 patches do in fact solve the problem we
were seeing.
- Bryan
[-- Attachment #2: Type: text/html, Size: 1036 bytes --]
next prev parent reply other threads:[~2020-04-21 14:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 18:33 Avoid copying unallocated clusters during full backup Leo Luan
2020-04-17 20:11 ` John Snow
2020-04-17 20:24 ` Eric Blake
2020-04-17 22:57 ` Leo Luan
2020-04-18 0:34 ` John Snow
2020-04-18 1:43 ` Leo Luan
2020-04-20 10:56 ` Vladimir Sementsov-Ogievskiy
2020-04-20 14:31 ` Bryan S Rosenburg
2020-04-20 15:04 ` Vladimir Sementsov-Ogievskiy
2020-04-21 14:41 ` Bryan S Rosenburg [this message]
2020-04-17 22:31 ` Leo Luan
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=OF1A8659FD.3A0BC2A3-ON85258551.00504BEA-85258551.0050B28F@notes.na.collabserv.com \
--to=rosnbrg@us.ibm.com \
--cc=jsnow@redhat.com \
--cc=leoluan@gmail.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel-bounces+rosnbrg=us.ibm.com@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.