search for: vixdisklibconnectparams

...READ_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS +#define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_REQUESTS + +/* Lock protecting open/close calls - see above. */ +static pthread_mutex_t open_close_lock = PTHREAD_MUTEX_INITIALIZER; /* The per-connection handle. */ struct vddk_handle { VixDiskLibConnectParams *params; /* connection parameters */ VixDiskLibConnection connection; /* connection */ VixDiskLibHandle handle; /* disk handle */ + int readonly; }; static inline VixDiskLibConnectParams * @@ -557,6 +569,7 @@ free_connect_params (VixDiskLibConnectParams *params) static void * v...

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.

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

...n_close_lock = PTHREAD_MUTEX_INITIALIZER; -/* The per-connection handle. */ +struct handle; struct vddk_handle { + VixDiskLibHandle vddk_handle; + bool in_use; + struct handle *h; +}; +DEFINE_VECTOR_TYPE(vddk_handles, struct vddk_handle) + +/* The per-connection handle. */ +struct handle { VixDiskLibConnectParams *params; /* connection parameters */ VixDiskLibConnection connection; /* connection */ - VixDiskLibHandle handle; /* disk handle */ + int readonly; /* readonly flag for this connection */ + uint32_t flags; /* open flags */ + + /* Pool of VDDK disk...

...-- plugins/vddk/vddk.c | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/plugins/vddk/vddk.c b/plugins/vddk/vddk.c index ca6ae6d6ff63..8cf54f6e2b96 100644 --- a/plugins/vddk/vddk.c +++ b/plugins/vddk/vddk.c @@ -428,6 +428,7 @@ struct vddk_handle { VixDiskLibConnectParams *params; /* connection parameters */ VixDiskLibConnection connection; /* connection */ VixDiskLibHandle handle; /* disk handle */ + VixDiskLibHandle handle_single_link; /* disk handle for single_link=true */ }; static inline VixDiskLibConnectParams * @@ -522,8 +523,6 @@ vddk_open...

..."vddk-stubs.h" -#undef STUB -#undef OPTIONAL_STUB +char * +VixDiskLib_GetErrorText (VixError err, const char *unused) +{ + return strdup ("dummy-vddk: error message"); +} + +void +VixDiskLib_FreeErrorText (char *text) +{ + free (text); +} + +void +VixDiskLib_FreeConnectParams (VixDiskLibConnectParams *params) +{ + /* never called since we don't define optional AllocateConnectParams */ + abort (); +} + +VixError +VixDiskLib_ConnectEx (const VixDiskLibConnectParams *params, + char read_only, + const char *snapshot_ref, + const c...

...-connection handle. */ > +struct handle; > struct vddk_handle { > + VixDiskLibHandle vddk_handle; > + bool in_use; > + struct handle *h; > +}; > +DEFINE_VECTOR_TYPE(vddk_handles, struct vddk_handle) > + > +/* The per-connection handle. */ > +struct handle { > VixDiskLibConnectParams *params; /* connection parameters */ > VixDiskLibConnection connection; /* connection */ > Given the poor results, I suspect that that handles created using same connection share a lock. This also makes sense if connection abstract a blocking socket. With multiple nbd connections we got...

...ODEL NBDKIT_THREAD_MODEL_SERIALIZE_REQUESTS > + > +/* Lock protecting open/close calls - see above. */ > +static pthread_mutex_t open_close_lock = PTHREAD_MUTEX_INITIALIZER; > > /* The per-connection handle. */ > struct vddk_handle { > @@ -524,6 +531,7 @@ free_connect_params (VixDiskLibConnectParams *params) > static void * > vddk_open (int readonly) > { > + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&open_close_lock); > struct vddk_handle *h; > VixError err; > uint32_t flags; > @@ -616,6 +624,7 @@ vddk_open (int readonly) > static void > vddk_close (void...

We had a query yesterday about the VDDK plugin and making it actually obey the weird "Multithreading Considerations" rules in the VDDK documentation (https://vdc-download.vmware.com/vmwb-repository/dcr-public/8f96698a-0e7b-4d67-bb6c-d18a1d101540/ef536a47-27cd-481a-90ef-76b38e75353c/vsphere-vddk-671-programming-guide.pdf) This patch is my attempt to implement this. The idea is that the

On Wed, Aug 05, 2020 at 02:39:44PM +0300, Nir Soffer wrote: > Can we use something like the file plugin? thread pool of workers, > each keeping open vddk handle, and serving requests in parallel from > the same nbd socket? Yes, but this isn't implemented in the plugins, it's implemented in the server. The server always uses a thread pool, but plugins can opt for more or less

Couple of fixes to return correct data and one nice-to-have clean-up which is not needed. I just find it nicer to read. Martin Kletzander (3): vddk: Use a separate handle for single-link=true vddk: Do not report hole extents to be zero with single-link=true vddk: Eliminate one needless goto plugins/vddk/vddk.c | 48 +++++++++++++++++++++++++++++++++------------ 1 file changed, 36

...sts can happen to different handles. > but it sounds to me like we need PARALLEL. > > With parallel we will have multiple threads using the same > vddk_handle, which can > be thread safe since we control this struct. > > The struct can be: > > struct vddk_item { > VixDiskLibConnectParams *params; /* connection parameters */ > VixDiskLibConnection connection; /* connection */ > VixDiskLibHandle handle; /* disk handle */ > struct vddk_item *next; /* next handle in the list */ > } > > struct vddk_handle { > struct vddm_items *pool; > pt...

...ZE_ALL_REQUESTS +#define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_REQUESTS + +/* Lock protecting open/close calls - see above. */ +static pthread_mutex_t open_close_lock = PTHREAD_MUTEX_INITIALIZER; /* The per-connection handle. */ struct vddk_handle { @@ -524,6 +531,7 @@ free_connect_params (VixDiskLibConnectParams *params) static void * vddk_open (int readonly) { + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&open_close_lock); struct vddk_handle *h; VixError err; uint32_t flags; @@ -616,6 +624,7 @@ vddk_open (int readonly) static void vddk_close (void *handle) { + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&am...

...not sure what is the difference between SERIALIZE_REQUESTS and SERIALIZE_ALL_REQUESTS, but it sounds to me like we need PARALLEL. With parallel we will have multiple threads using the same vddk_handle, which can be thread safe since we control this struct. The struct can be: struct vddk_item { VixDiskLibConnectParams *params; /* connection parameters */ VixDiskLibConnection connection; /* connection */ VixDiskLibHandle handle; /* disk handle */ struct vddk_item *next; /* next handle in the list */ } struct vddk_handle { struct vddm_items *pool; pthread_mutex_t *mutex; } open() will ini...

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

...but it sounds to me like we need PARALLEL. > > > > With parallel we will have multiple threads using the same > > vddk_handle, which can > > be thread safe since we control this struct. > > > > The struct can be: > > > > struct vddk_item { > > VixDiskLibConnectParams *params; /* connection parameters */ > > VixDiskLibConnection connection; /* connection */ > > VixDiskLibHandle handle; /* disk handle */ > > struct vddk_item *next; /* next handle in the list */ > > } > > > > struct vddk_handle { > > st...

Probably needs a bit of cleanup, but seems like it is generally the right direction. One thing I've noticed is that the expect test randomly (but rarely) hangs :-( I guess something is racey but I don't know what at the moment. Rich.

...+ expect "ssword:" + send "abc\r" + wait +EOF +cat $out + +grep "password=abc$" $out diff --git a/tests/dummy-vddk.c b/tests/dummy-vddk.c index 13be492d..a2377944 100644 --- a/tests/dummy-vddk.c +++ b/tests/dummy-vddk.c @@ -91,6 +91,12 @@ VixDiskLib_ConnectEx (const VixDiskLibConnectParams *params, const char *transport_modes, VixDiskLibConnection *connection) { + /* Used when regression testing password= parameter. */ + if (getenv ("DUMMY_VDDK_PRINT_PASSWORD") && + params->credType == VIXDISKLIB_CRED_UID &amp...