Re: [Libguestfs] [PATCH nbdkit v5 FINAL 14/19] data, memory: Implement extents.
On 4/23/19 4:49 PM, Richard W.M. Jones wrote:
>
> ...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?
It's a bit late at night for me to think clearly about extents, but
here is a description of the original problem with moving the clamp:
https://www.redhat.com/archives/libguestfs/2019-March/msg00202.html
Thanks for finding that link:
Imagine an allocated RAM disk with a size smaller than the 32K page
size of the sparse array:
nbdkit data data="1" size=512
This will return extents information: [length=32768, type=data].
This doesn't matter for qemu which appears to ignore the extra
information, but it causes a bug if we place the truncate filter on
top:
nbdkit --filter=truncate data data="1" size=512 truncate=64K
This now returns the following extents information which is wrong:
[length=32768, type=data]
[length=32768, type=hole|zero]
But since then, we've fixed the truncate filter to allocate a second
extents bounded by the truncation size to hand to next_ops->extents, so
even if the plugin calls nbdkit_add_extent with information beyond the
length that the truncation filter cares about, the result is still
bounded to the truncation's choice of end offset. So I think we have
indeed fixed the initial problem.
I'll see if this still applies tomorrow morning ...
No rush :)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 488 bytes)