On 3/29/19 3:33 AM, Richard W.M. Jones wrote: >>> + /* We're asked first for extents information about the plugin, then >>> + * possibly (if truncating larger) for the hole after the plugin. >>> + * Since we're not required to provide all of this information, the >>> + * easiest thing is to only return data from the plugin. We will be >>> + * called later about the hole. However we do need to make sure >>> + * that the extents array is truncated to the real size, hence we >>> + * have to create a new extents array, ask the plugin, then copy the >>> + * returned data to the original array. >>> + */ >>> + extents2 = nbdkit_extents_new (0, real_size_copy); >> >> Why 0 for start instead of offset? You get the same result either way >> (since the copying code ignores the prefix), but it's probably a lot >> more efficient to not have to copy the extents for the prefix of the file. > > Yup that's a mistake too :-(
Thanks for the quick fix. I realized that it is not just an efficiency problem, but an actual bug - if the plugin returns exactly one extent, it ends up not covering the start offset of the original extents, at which point the truncate filter returns success with 0 extents instead of the requirement of at least 1. While the 'end' parameter does not drive correct results, the 'start' parameter does :) -- 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
