search for: xz_prepare

.../xz/xz.c index 26cfa959..2aa8c893 100644 --- a/filters/xz/xz.c +++ b/filters/xz/xz.c @@ -47,6 +47,7 @@ #include "xzfile.h" #include "blkcache.h" +#include "cleanup.h" static uint64_t maxblock = 512 * 1024 * 1024; static uint32_t maxdepth = 8; @@ -156,6 +157,21 @@ xz_prepare (struct nbdkit_next_ops *next_ops, void *nxdata, void *handle, return 0; } +/* Description. */ +static const char * +xz_export_description (struct nbdkit_next_ops *next_ops, void *nxdata, + void *handle) +{ + const char *base = next_ops->export_description (nxdata); +...

...ters/xz/xz.c > +++ b/filters/xz/xz.c > @@ -47,6 +47,7 @@ > > #include "xzfile.h" > #include "blkcache.h" > +#include "cleanup.h" > > static uint64_t maxblock = 512 * 1024 * 1024; > static uint32_t maxdepth = 8; > @@ -156,6 +157,21 @@ xz_prepare (struct nbdkit_next_ops *next_ops, void *nxdata, void *handle, > return 0; > } > > +/* Description. */ > +static const char * > +xz_export_description (struct nbdkit_next_ops *next_ops, void *nxdata, > + void *handle) > +{ > + const char *base...

I'm not sure that this fix is really correct. An alternate way I can think to fix this would be for the core server to maintain a readonly flag for each layer (instead of just per- server). You could also argue that our readonly test in server/connections.c:compute_eflags is wrong and/or that the implementations of server/plugins.c:plugin_can_write and server/filters.c:filter_can_write have

Applies on top of my pending series for the exportname filter, addressing one of the todo's in that cover letter. Eric Blake (2): filters: Add .export_description wrappers ext2: Supply .list_exports and .default_export filters/ext2/nbdkit-ext2-filter.pod | 3 +- tests/Makefile.am | 16 +++- filters/ext2/ext2.c | 125 +++++++++++++++++++---------

..._ops *next_ops, void *nxdata, + void *handle) +{ + return 0; +} + /* Read data from the file. */ static int xz_pread (struct nbdkit_next_ops *next_ops, void *nxdata, @@ -225,6 +232,7 @@ static struct nbdkit_filter filter = { .close = xz_close, .prepare = xz_prepare, .get_size = xz_get_size, + .can_write = xz_can_write, .pread = xz_pread, }; -- 2.20.1

v2: - Fixes a number of bugs in corner cases. - Uses a 1M block size to fetch from the underlying plugin. This improves performance considerably. I also tested this much more thoroughly and can't find any more bugs. Rich.

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

...,6 +257,7 @@ static struct nbdkit_filter filter = { .version = PACKAGE_VERSION, .config = xz_config, .config_help = xz_config_help, + .thread_model = xz_thread_model, .open = xz_open, .close = xz_close, .prepare = xz_prepare, diff --git a/server/filters.c b/server/filters.c index 87a9c0e..3d9e1ef 100644 --- a/server/filters.c +++ b/server/filters.c @@ -93,20 +93,18 @@ static int filter_thread_model (struct backend *b) { struct backend_filter *f = container_of (b, struct backend_filter, backend); - int filter_thre...

Being able to programmatically force nbdkit to be less parallel can be useful during testing. I was less sure about patch 3, but if you like it, I'm inclined to instead squash it into patch 1. This patch is written to apply after my NBD_CMD_CACHE work (since I touched the nocache filter); but can be rearranged if we think this series should go in first while that one undergoes any adjustments

It's been several weeks since I posted v2 (I got distracted by improving libnbd to better test things, which in turn surfaced some major memory leak problems in nbdsh that are now fixed). Many of the patches are minor rebases from v2, with the biggest changes being fallout from: - patch 2: rename nbdkit_add_default_export to nbdkit_use_default_export - overall: this missed 1.22, so update

I'm not sure exactly which version we're up to, but let's say it's version 4. I'm a lot happier with this version: - all filters have been reviewed and changed where I think that's necessary - can_extents is properly defined and implemented now - NBD protocol is followed - I believe it addresses all previous review points where possible The "only" thing

This has already been pushed upstream. I am simply posting these here so we have a reference in the mailing list in case we find bugs later (as I'm sure we will - it's a complex patch series). Great thanks to Eric Blake for tireless review on this one. It also seems to have identified a few minor bugs in qemu along the way. Rich.