[Libguestfs] [PATCH nbdkit] New ondemand plugin.

[Eric Blake]

On 8/15/20 4:13 PM, Richard W.M. Jones wrote:

>>> +/* Because we rewind the exportsdir handle, we need a lock to protect
>>> + * list_exports from being called in parallel.
>>> + */
>>> +static pthread_mutex_t exports_lock = PTHREAD_MUTEX_INITIALIZER;
>>
>> An alternative is to diropen() each time .list_exports gets called.
>> Either way should work, though.
> 
> diropen == opendir?

Oops, yeah.

> 
>> I still have some pending patches to improve .list_exports (split
>> out a .default_export function, add an is_tls parameter), so there
>> may be some churn in this area (for that matter, I have not yet
>> pushed my patches for .list_exports in the file plugin, because I
>> was trying to minimize churn while working on pending patches).
>> We'll just have to see how it goes; I don't mind rebasing.
> 
> Right - this is indeed one major reason I sent this for review - it's
> a new plugin which integrally uses list_exports.
> 

Okay, once my libnbd stuff settles, I'll be able to get back to 
finalizing how the .list_exports stuff should work in nbdkit.

>>> +/* Since clients that want multi-conn should all pass the same export
>>> + * name, this is safe.
>>> + */
>>> +static int
>>> +ondemand_can_multi_conn (void *handle)
>>> +{
>>> +  return 1;
>>> +}
>>
>> Hmm. Are you permitting multiple clients to the same export, or did
>> you decide that was too likely to cause fs corruption, and locking
>> out users on the same export?  The docs above said otherwise, making
>> this look wrong.
> 
> So I think this is wrong because my locking implementation will
> prevent the (single) client from connecting multiple times.  That's a
> bug: we should allow the same client to connect multiple times, which
> I believe is safe.  However that requires client UUID ...
> 

Hence your protocol enhancement proposal.  Yeah, letting a client tell 
the server during handshaking about both UUID and intent to be read-only 
vs. read-write are now seeming more worthwhile.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org