On 3/28/19 11:18 AM, Richard W.M. Jones wrote:
These plugins are both based on the same sparse array structure
which
supports a simple implementation of extents.
---
common/sparse/sparse.h | 7 +-
common/sparse/sparse.c | 37 ++++++++++-
plugins/data/data.c | 16 ++++-
plugins/memory/memory.c | 16 ++++-
README | 2 +
tests/Makefile.am | 2 +
tests/test-data-extents.sh | 131 +++++++++++++++++++++++++++++++++++++
7 files changed, 207 insertions(+), 4 deletions(-)
+int
+sparse_array_extents (struct sparse_array *sa,
+ uint32_t count, uint64_t offset,
+ struct nbdkit_extents *extents)
+{
+ uint32_t n, type;
+ void *p;
+
+ while (count > 0) {
+ p = lookup (sa, offset, false, &n, NULL);
+ if (n > count)
+ n = count;
I know in earlier review I asked whether we can move the clamping...
+
+ /* Work out the type of this extent. */
+ if (p == NULL)
+ /* No backing page, so it's a hole. */
+ type = NBDKIT_EXTENT_HOLE | NBDKIT_EXTENT_ZERO;
+ else {
+ if (is_zero (p, n))
+ /* A backing page and it's all zero, it's a zero extent. */
+ type = NBDKIT_EXTENT_ZERO;
+ else
+ /* Normal allocated data. */
+ type = 0;
+ }
+ if (nbdkit_add_extent (extents, offset, n, type) == -1)
+ return -1;
+
...to here, after the final nbdkit_add_extent, so that we can return a
larger extent than the client's request. I remember when I originally
asked, you declined due to odd interactions with REQ_ONE semantics, but
since then, we changed how add_extent() works. Does it work now to defer
the clamping?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org