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

[Richard W.M. Jones]

On Fri, Jan 19, 2018 at 10:39:09AM -0600, Eric Blake wrote:
> 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).

See the TODO file for my idea on that one:

https://github.com/libguestfs/nbdkit/blob/b22fff03d933bc3b25eaf1d40f45dcd063568bd6/TODO#L64

> 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?

Yes, that's a good idea, will implement.

> > +
> > +=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?

Yes, also a good idea.

> > +
> > +=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)?

Yes it's an error and it needs an extra check.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top