On 3/28/19 11:18 AM, Richard W.M. Jones wrote:
 ---
  filters/truncate/truncate.c | 55 +++++++++++++++++++++++++++++++++++++
  1 file changed, 55 insertions(+)
  
 +
 +  /* If the entire request is beyond the end of the underlying plugin
 +   * then this is the easy case: return a hole.
 +   */
 +  if (offset >= real_size_copy)
 +    return nbdkit_add_extent (extents, offset, (uint64_t) count,
 +                              NBDKIT_EXTENT_ZERO|NBDKIT_EXTENT_HOLE); 
Why not return a hole up to the end of the file, rather than limiting
things at the end of the client's request?
 +
 +  /* 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.
-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  
qemu.org | 
libvirt.org