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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
