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 _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
