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