qemu-commits
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]