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
