qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH 0/3] Exposing backing-chain allocation over NBD


From: Eric Blake
Subject: [PATCH 0/3] Exposing backing-chain allocation over NBD
Date: Fri, 25 Sep 2020 15:32:46 -0500

I'm working on preparing my KVM Forum presentation on NBD, and ran
into a situation where I really wanted to do the equivalent of
'qemu-img map' over NBD for determining which portions of an overlay
image are changed from the backing layer.  So after less than 24 hours
hacking, I'm pretty pleased with the results.

Known caveats:

- Probably has lots of conflicts with Kevin's pending work on
  refactoring NBD for nicer use in qemu-storage-daemon

- Not yet tested with Vladimir's patches to fix bdrv_block_status bugs
  when the backing file is short (and therefore, applying this series
  without that is likely to make it possible to expose the same bugs
  of wrong information)

- I _still_ want to get QMP 'block-dirty-bitmap-populate' in qemu 5.2;
  with that in place, you could avoid the need for this series by
  instead populating a temporary bitmap and exposing that bitmap over
  NBD instead.  But that requires more work, both in coding (Peter
  Krempa and I still need to make sure we have the ideal QMP
  interface) and in usage (managing temporary bitmaps is more effort
  than a new bool toggle).

- And if we _did_ use block-dirty-bitmap-populate, I find myself
  wanting to be able to expose more than one bitmap at a time over
  NBD, which in turn means revisiting our current QAPI for
  nbd-server-add of '*bitmap':'str' to instead allow an alternate type
  that permits either "'str'" or "['str']", except that our QAPI
  generator does not yet support arrays in alternates, and is
  undergoing changes from John Snow for python cleanups...

- I am aware of long-standing qemu bugs where when we advertise a
  large minimum block size (say 4k) but the backing file has smaller
  granularity (such as 512), then we can violate NBD protocol by
  sending a reply to NBD_CMD_BLOCK_STATUS with misaligned data.  This
  adds yet another instance of being able to tickle that (rare) bug.
  I really need to revisit my patches to add
  bdrv_block_status_aligned...

Also available at:
https://repo.or.cz/qemu/ericb.git/shortlog/refs/tags/nbd-alloc-depth-v1

Eric Blake (3):
  nbd: Simplify meta-context parsing
  nbd: Add new qemu:allocation-depth metacontext
  nbd: Add 'qemu-nbd -A' to expose allocation depth

 docs/interop/nbd.txt       |  22 ++-
 docs/tools/qemu-nbd.rst    |   6 +
 qapi/block-core.json       |  13 +-
 include/block/nbd.h        |  15 +-
 blockdev-nbd.c             |   3 +-
 nbd/server.c               | 294 ++++++++++++++++++++-----------------
 qemu-nbd.c                 |  16 +-
 tests/qemu-iotests/309     |  73 +++++++++
 tests/qemu-iotests/309.out |  22 +++
 tests/qemu-iotests/group   |   1 +
 10 files changed, 310 insertions(+), 155 deletions(-)
 create mode 100755 tests/qemu-iotests/309
 create mode 100644 tests/qemu-iotests/309.out

-- 
2.28.0




reply via email to

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