On 11/21/18 9:59 AM, Eric Blake wrote:
On 11/21/18 9:46 AM, Richard W.M. Jones wrote:
Matt asked if xz should really be a filter rather than a plugin. The
answer is yes, of course it should be! That's been something in the
todo file for a while.
The commit converts the xz plugin code into a filter (leaving the
plugin around, but deprecating it).
plugin: nbdkit xz file.xz
filter: nbdkit --filter=xz file file.xz
plugin: # can't be done
filter: nbdkit --filter=xz curl url=https://example.com/disk.xz
And further:
nbdkit --filter=cache --filter=xz curl url=...
to take advantage of local caching rather than repeated curl requests.
Actually, after reading patch 1, I see that you already do some caching
directly in the xz filter (copied from the xz plugin), so sticking
--filter=cache in front of --filter=xz probably won't buy much
performance, but using:
nbdkit --filter=xz --filter=cache curl url=...
will have two layers of caching (one of the compressed xz data read from
curl, another of the uncompressed data in the xz filter). Or, we could
argue that the xz filter itself doesn't need to concern itself with
caching (for less code in the xz filter), and just recommend that the
user supply the --filter=cache themselves for performance (but then you
wonder if we should start considering nbdkit being able to use the same
filter more than once in its chain, which right now is not possible).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
_______________________________________________
Libguestfs mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libguestfs
