On 6/28/20 4:35 PM, Richard W.M. Jones wrote:
For completeness here are the other ways I investigated:
* Make generic read, write, zero, trim, extents operations on local
files. The file-like plugins would consume those directly, after
doing any adjustments eg for offset. Unfortunately the operations
that you have to write are not very "pure" and depend on a bunch of
state across calls and you end up not having much common code:
https://github.com/libguestfs/nbdkit/blob/f6d4365364f2c90dde0166ae4355f74...
* Have the new tar plugin re-exec nbdkit and run the ordinary file
plugin + offset filter. After experience with the VDDK plugin which
does this through necessity, I don't want to go there right now.
See this file to understand the kind of complexity this introduces:
https://github.com/libguestfs/nbdkit/blob/master/plugins/vddk/reexec.c
* Instead of writing a tar plugin, write a wrapper script which hands
off to file plugin + offset filter. From the user's point of view
the script would work a lot differently from other plugins.
So no good ideas so far.
How hard is it to write a tar filter instead of a tar plugin (similar to
how we moved ext2 from plugin to filter)?
- During .get_ready, we have to find some way to read the underlying
plugin to feed a pipeline to tar to decode what the file contains (we
can't just hand the file to tar, but instead have to feed it data
through stdin; but the amount of work is no different: tar really does
have to read the entire image during 'tar tRvf').
- There would no longer be a tar=... parameter, rather that is the role
of the plugin
- We'd have to rename the file=... parameter to something that won't
conflict with the most common use of having the file plugin serve the
tar file
- But once we've done the .get_ready scan of the entire tar file, we can
then service offsets to the plugin similarly to how the offset filter works
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org