search for: vddk_get_size

...andle"); @@ -659,6 +674,14 @@ vddk_close (void *handle) free (h); } +/* Allow multi-conn - see comment about threading above. */ +static int +vddk_can_multi_conn (void *handle) +{ + struct vddk_handle *h = handle; + return h->readonly; +} + /* Get the file size. */ static int64_t vddk_get_size (void *handle) @@ -986,6 +1009,7 @@ static struct nbdkit_plugin plugin = { .after_fork = vddk_after_fork, .open = vddk_open, .close = vddk_close, + .can_multi_conn = vddk_can_multi_conn, .get_size = vddk_get_size, .pread = vddk...

In theory this patch depends on this series: https://www.redhat.com/archives/libguestfs/2020-August/msg00021.html In practice I believe they're independent of each other, but the above series makes it easier to test. Rich.

...static struct nbdkit_plugin plugin = { .magic_config_key = "file", .dump_plugin = vddk_dump_plugin, .get_ready = vddk_get_ready, + .after_fork = vddk_after_fork, .open = vddk_open, .close = vddk_close, .get_size = vddk_get_size, -- 2.25.0

...ctor += nr_sectors; + + if (req_one) + break; + } + + return 0; +} + static struct nbdkit_plugin plugin = { .name = "vddk", .longname = "VMware VDDK plugin", @@ -585,6 +721,8 @@ static struct nbdkit_plugin plugin = { .get_size = vddk_get_size, .pread = vddk_pread, .pwrite = vddk_pwrite, + .can_extents = vddk_can_extents, + .extents = vddk_extents, }; NBDKIT_REGISTER_PLUGIN(plugin) -- 2.20.1

I believe this roughly implements Nir's proposal here: https://www.redhat.com/archives/libguestfs/2020-August/msg00028.html Unfortunately it doesn't work for me. It actually slows things down quite a lot, for reasons I don't understand. Note the adjustment of the pool-max parameter and how it affects the total time. The results are quite reproducible. $ ./nbdkit -r -U - vddk

...;connection"); VixDiskLib_Disconnect (h->connection); free_connect_params (h->params); + pthread_cond_destroy (&h->vddk_handles_cond); + pthread_mutex_destroy (&h->vddk_handles_lock); free (h); } @@ -639,13 +746,14 @@ vddk_close (void *handle) static int64_t vddk_get_size (void *handle) { - struct vddk_handle *h = handle; + struct handle *h = handle; + GET_VDDK_HANDLE_FOR_CURRENT_SCOPE (h, vddk_handle); VixDiskLibInfo *info; VixError err; uint64_t size; DEBUG_CALL ("VixDiskLib_GetInfo", "handle, &info"); - err = VixDiskLib_...

...t (h->connection); > free_connect_params (h->params); > + pthread_cond_destroy (&h->vddk_handles_cond); > + pthread_mutex_destroy (&h->vddk_handles_lock); > free (h); > } > > @@ -639,13 +746,14 @@ vddk_close (void *handle) > static int64_t > vddk_get_size (void *handle) > { > - struct vddk_handle *h = handle; > + struct handle *h = handle; > + GET_VDDK_HANDLE_FOR_CURRENT_SCOPE (h, vddk_handle); > VixDiskLibInfo *info; > VixError err; > uint64_t size; > > DEBUG_CALL ("VixDiskLib_GetInfo", "han...

I like this change. I think we were overloading the config_complete method before to do two different things (complete configuration; do any allocation/housekeeping necessary before we can start serving). The only questions in my mind are whether we want this before 1.18, and whether the name ("get_ready") is a good one. Rich.

If you have a plugin which either creates background threads itself or uses a library that creates background threads, it turns out you cannot create these in .get_ready (or earlier). The reason is that nbdkit forks when either daemonizing itself or using the --run option, and fork cancels all the background threads in the child process (the daemonized or captive nbdkit). The only good solution

This is my second attempt at this. The first version (also not working) was here: https://www.redhat.com/archives/libguestfs/2019-October/msg00062.html In part 1/2 I introduce a new .ready_to_serve plugin method which is called after forking and just before accepting any client connection. The idea would be that plugins could start background threads here. However this doesn't work well in

Not sure what version we're up to, but this reimplements extents using the new simpler structure described in this thread: https://www.redhat.com/archives/libguestfs/2019-March/msg00077.html I also fixed most of the things that Eric pointed out in the previous review, although I need to go back over his replies and check I've got everything. This needs a bit more testing. However the

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

I want to post this but mainly for discussion and early review. It's not safe for these patches to all go upstream yet (because not all filters have been checked/adjusted), but if any patches were to go upstream then probably 1 & 2 only are safe. File, VDDK, memory and data plugins all work, although I have only done minimal testing on them. The current tests, such as they are, all

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.