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.
This is only lightly tested but it works for local files and for the
curl example given in the commit message. Unfortunately because of
the very large block size used in the Fedora cloud image, the curl
example is barely usable. We should get them to use a more reasonable
block size such as 16M (currently 192M).
This may be the first real random-access of a remote xz file that makes
the argument for a smaller block size :)
Of course, when you switch to a smaller block size, the xz image can't
compress quite as far, but hopefully the size difference is not that
bad. Do you have actual numbers comparing the file size, vs. the speed
changes made possible by the difference in block size?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org