qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: peter.maydell@linaro.org,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org,
	qemu-stable@nongnu.org, John Snow <jsnow@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 for-4.1 0/2] backup: Copy only dirty areas
Date: Fri, 2 Aug 2019 15:50:26 +0200	[thread overview]
Message-ID: <6d3b3fd2-dc14-57bd-9d54-91c5c6deb4eb@redhat.com> (raw)
In-Reply-To: <20190802133428.GC6379@localhost.localdomain>


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

On 02.08.19 15:34, Kevin Wolf wrote:
> Am 01.08.2019 um 19:38 hat Max Reitz geschrieben:
>> 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...
> 
> This sounds bad indeed. But are we already going to have an -rc4 for
> other reasons, or would this mean to have one only for the backup fix?

Looks like we are going to have an rc4 in any case because of the slirp
submodule.

> Also, if you say this was broken in 4.0, Cc: qemu-stable

Oh, right.  I have been forgetting that for quite a while now.

Max



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

  reply	other threads:[~2019-08-02 13:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-01 17:38 [Qemu-devel] [PATCH v2 for-4.1 0/2] backup: Copy only dirty areas Max Reitz
2019-08-01 17:38 ` [Qemu-devel] [PATCH v2 for-4.1 1/2] " 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 [this message]
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=6d3b3fd2-dc14-57bd-9d54-91c5c6deb4eb@redhat.com \
    --to=mreitz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).