[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 4a5b91: backup: Copy only dirty areas
From: |
Peter Maydell |
Subject: |
[Qemu-commits] [qemu/qemu] 4a5b91: backup: Copy only dirty areas |
Date: |
Tue, 06 Aug 2019 07:44:00 -0700 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: 4a5b91ca024fc6fd87021c54655af76a35f2ef1e
https://github.com/qemu/qemu/commit/4a5b91ca024fc6fd87021c54655af76a35f2ef1e
Author: Max Reitz <address@hidden>
Date: 2019-08-06 (Tue, 06 Aug 2019)
Changed paths:
M block/backup.c
Log Message:
-----------
backup: Copy only dirty areas
The backup job must only copy areas that the copy_bitmap reports as
dirty. This is always the case when using traditional non-offloading
backup, because it copies each cluster separately. When offloading the
copy operation, we sometimes copy more than one cluster at a time, but
we only check whether the first one is dirty.
Therefore, whenever copy offloading is possible, the backup job
currently produces wrong output when the guest writes to an area of
which an inner part has already been backed up, because that inner part
will be re-copied.
Fixes: 9ded4a0114968e98b41494fc035ba14f84cdf700
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-id: address@hidden
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Commit: 5f594a2e99f19ca0f7744d333bcd556f5976b78f
https://github.com/qemu/qemu/commit/5f594a2e99f19ca0f7744d333bcd556f5976b78f
Author: Max Reitz <address@hidden>
Date: 2019-08-06 (Tue, 06 Aug 2019)
Changed paths:
M tests/qemu-iotests/056
M tests/qemu-iotests/056.out
Log Message:
-----------
iotests: Test backup job with two guest writes
Perform two guest writes to not yet backed up areas of an image, where
the former touches an inner area of the latter.
Before HEAD^, copy offloading broke this in two ways:
(1) The target image differs from the reference image (what the source
was when the backup started).
(2) But you will not see that in the failing output, because the job
offset is reported as being greater than the job length. This is
because one cluster is copied twice, and thus accounted for twice,
but of course the job length does not increase.
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Tested-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
Commit: 4e4de222799634d8159ee7b9303b9e1b45c6be2c
https://github.com/qemu/qemu/commit/4e4de222799634d8159ee7b9303b9e1b45c6be2c
Author: Vladimir Sementsov-Ogievskiy <address@hidden>
Date: 2019-08-06 (Tue, 06 Aug 2019)
Changed paths:
M util/hbitmap.c
Log Message:
-----------
util/hbitmap: update orig_size on truncate
Without this, hbitmap_next_zero and hbitmap_next_dirty_area are broken
after truncate. So, orig_size is broken since it's introduction in
76d570dc495c56bb.
Fixes: 76d570dc495c56bb
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-id: address@hidden
Reviewed-by: Max Reitz <address@hidden>
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Commit: 8a9cb864086269af14bbd13f395472703cf99f8c
https://github.com/qemu/qemu/commit/8a9cb864086269af14bbd13f395472703cf99f8c
Author: Max Reitz <address@hidden>
Date: 2019-08-06 (Tue, 06 Aug 2019)
Changed paths:
M tests/qemu-iotests/124
M tests/qemu-iotests/124.out
Log Message:
-----------
iotests: Test incremental backup after truncation
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Commit: 9adc1cb49af8d4e54f57980b1eed5c0a4b2dafa6
https://github.com/qemu/qemu/commit/9adc1cb49af8d4e54f57980b1eed5c0a4b2dafa6
Author: Max Reitz <address@hidden>
Date: 2019-08-06 (Tue, 06 Aug 2019)
Changed paths:
M block/mirror.c
Log Message:
-----------
mirror: Only mirror granularity-aligned chunks
In write-blocking mode, all writes to the top node directly go to the
target. We must only mirror chunks of data that are aligned to the
job's granularity, because that is how the dirty bitmap works.
Therefore, the request alignment for writes must be the job's
granularity (in write-blocking mode).
Unfortunately, this forces all reads and writes to have the same
granularity (we only need this alignment for writes to the target, not
the source), but that is something to be fixed another time.
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Fixes: d06107ade0ce74dc39739bac80de84b51ec18546
Signed-off-by: Max Reitz <address@hidden>
Commit: 19ba4651fe2d17cc49adae29acbb4a8cc29db8d1
https://github.com/qemu/qemu/commit/19ba4651fe2d17cc49adae29acbb4a8cc29db8d1
Author: Max Reitz <address@hidden>
Date: 2019-08-06 (Tue, 06 Aug 2019)
Changed paths:
M tests/qemu-iotests/151
M tests/qemu-iotests/151.out
Log Message:
-----------
iotests: Test unaligned blocking mirror write
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
Commit: 110571be4e70ac015628e76d2731f96dd8d1998c
https://github.com/qemu/qemu/commit/110571be4e70ac015628e76d2731f96dd8d1998c
Author: Vladimir Sementsov-Ogievskiy <address@hidden>
Date: 2019-08-06 (Tue, 06 Aug 2019)
Changed paths:
M block/backup.c
Log Message:
-----------
block/backup: disable copy_range for compressed backup
Enabled by default copy_range ignores compress option. It's definitely
unexpected for user.
It's broken since introduction of copy_range usage in backup in
9ded4a011496.
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-id: address@hidden
Reviewed-by: John Snow <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Commit: df1a7c99dd5392212e70f75f6131d2e647330c17
https://github.com/qemu/qemu/commit/df1a7c99dd5392212e70f75f6131d2e647330c17
Author: Peter Maydell <address@hidden>
Date: 2019-08-06 (Tue, 06 Aug 2019)
Changed paths:
M block/backup.c
M block/mirror.c
M tests/qemu-iotests/056
M tests/qemu-iotests/056.out
M tests/qemu-iotests/124
M tests/qemu-iotests/124.out
M tests/qemu-iotests/151
M tests/qemu-iotests/151.out
M util/hbitmap.c
Log Message:
-----------
Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2019-08-06'
into staging
Block patches for 4.1.0-rc4:
- Fix the backup block job when using copy offloading
- Fix the mirror block job when using the write-blocking copy mode
- Fix incremental backups after the image has been grown with the
respective bitmap attached to it
# gpg: Signature made Tue 06 Aug 2019 12:57:07 BST
# gpg: using RSA key 91BEB60A30DB3E8857D11829F407DB0061D5CF40
# gpg: issuer "address@hidden"
# gpg: Good signature from "Max Reitz <address@hidden>" [full]
# Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40
* remotes/maxreitz/tags/pull-block-2019-08-06:
block/backup: disable copy_range for compressed backup
iotests: Test unaligned blocking mirror write
mirror: Only mirror granularity-aligned chunks
iotests: Test incremental backup after truncation
util/hbitmap: update orig_size on truncate
iotests: Test backup job with two guest writes
backup: Copy only dirty areas
Signed-off-by: Peter Maydell <address@hidden>
Compare: https://github.com/qemu/qemu/compare/9bb68d34dda9...df1a7c99dd53
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 4a5b91: backup: Copy only dirty areas,
Peter Maydell <=