Re: [Libguestfs] [PATCH nbdkit 2/2] tar: Rewrite the tar plugin (again), this time in C.

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