[Qemu-devel] [PATCH for-4.1 0/2] backup: Copy only dirty areas

Max Reitz posted 2 patches 4 years, 8 months ago
Test FreeBSD passed
Test asan passed
Test docker-mingw@fedora passed
Test docker-clang@ubuntu passed
Test s390x failed
Test checkpatch passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20190801151235.8434-1-mreitz@redhat.com
Maintainers: John Snow <jsnow@redhat.com>, Max Reitz <mreitz@redhat.com>, Kevin Wolf <kwolf@redhat.com>
There is a newer version of this series
block/backup.c             | 13 +++++++++++--
tests/qemu-iotests/056     | 34 ++++++++++++++++++++++++++++++++++
tests/qemu-iotests/056.out |  4 ++--
3 files changed, 47 insertions(+), 4 deletions(-)
[Qemu-devel] [PATCH for-4.1 0/2] backup: Copy only dirty areas
Posted by Max Reitz 4 years, 8 months ago
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...


Max Reitz (2):
  backup: Copy only dirty areas
  iotests: Test backup job with two guest writes

 block/backup.c             | 13 +++++++++++--
 tests/qemu-iotests/056     | 34 ++++++++++++++++++++++++++++++++++
 tests/qemu-iotests/056.out |  4 ++--
 3 files changed, 47 insertions(+), 4 deletions(-)

-- 
2.21.0


Re: [Qemu-devel] [PATCH for-4.1 0/2] backup: Copy only dirty areas
Posted by Vladimir Sementsov-Ogievskiy 4 years, 8 months ago
01.08.2019 18:12, Max Reitz wrote:
> 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...
> 

Agree. And if this goes into 4.1, I suggest to add
[PATCH 2/3] block/backup: disable copy_range for compressed backup

as for now compressed backup just don't compress anything on FS with
copy offloading supported.

> 
> Max Reitz (2):
>    backup: Copy only dirty areas
>    iotests: Test backup job with two guest writes
> 
>   block/backup.c             | 13 +++++++++++--
>   tests/qemu-iotests/056     | 34 ++++++++++++++++++++++++++++++++++
>   tests/qemu-iotests/056.out |  4 ++--
>   3 files changed, 47 insertions(+), 4 deletions(-)
> 


-- 
Best regards,
Vladimir