[Libguestfs] [PATCH nbdkit filters-v2 3/5] filters: Add nbdkit-offset-filter.

[Eric Blake]

On 01/19/2018 09:23 AM, Richard W.M. Jones wrote:
> This very basic filter allows you to select an offset and range within
> a plugin, for example:
> 
>  nbdkit --filter=offset file file=foo offset=1M range=100M
> 
> which serves the byte range [ 1M .. 101M-1 ] from file ‘foo’.

I wonder - would it be possible to write a filter that performs
concatenation?  I know we don't support multiple uses of a plugin in the
same nbdkit process, but it might be possible to have a filter that
allows '0..m-1' to forward to the normal plugin, and 'm..n-1' to forward
to a forked nbdkit started on the nbd plugin wrapping the second use of
the normal plugin (ie. you can't concatenate two uses of the nbd plugin,
but you CAN concatenate the nbd plugin and any other plugin, with the
end appearance of using the file plugin twice from a single nbdkit
command line).

Anyways, that's food for another patch, and I only thought about it as
the inverse of what this filter is doing.

> +=over 4
> +
> +=item B<offset=OFFSET>
> +
> +The start offset.
> +
> +This parameter is required.

Can we support an implicit offset=0 if range= is provided (that is, the
filter requires that at least one parameter appears)?  Can we support
negative offsets as meaning relative to the end of the underlying file?

> +
> +=item B<range=LENGTH>
> +
> +The length of data to serve.
> +
> +This is optional.  If not given then the range is served starting from
> +the offset through to the end of the underlying file/device.

Should we support negative ranges as a way to trim off that much of the
tail of the file?

> +
> +=back
> +
> +Note it is an error if the range parameter is supplied and
> +C<offset+range> is larger than the size of data served by the
> +underlying plugin.

Is it also an error if offset exceeds the size of the file?  Is there a
technical limitation why range has to be non-zero, or can we allow
serving a 0-length file (may be relevant later on when resize support
comes into play)?


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20180119/fcee37a7/attachment.sig>