[Libguestfs] [libnbd PATCH 1/3] commands: Preserve FIFO ordering
Eric Blake
eblake at redhat.com
Tue May 21 15:25:49 UTC 2019
On 5/21/19 10:09 AM, Eric Blake wrote:
> A generic client exploiting multiple in-flight commands should be
> prepared for out-of-order responses (and should probably ensure that
> there are no overlaps between parallel in-flight commands to avoid
> unspecified disk contents if the server acts on commands in an
> arbitrary order or even exposing non-atomic splicing effects). But a
> specific client aware of a specific server's behavior of being fully
> serialized may depend on commands being processed in strict FIFO
> order, and we should not get in the way of that. When adding commands
> to be issued, and when moving a server's reply into commands to inform
> the client about, we need to insert at the end rather than the head of
> the appropriate list. Only the cmds_in_flight list does not have to
> care about maintaining FIFO ordering.
> ---
> generator/states-reply.c | 13 ++++++++++---
> lib/rw.c | 13 ++++++++++---
> 2 files changed, 20 insertions(+), 6 deletions(-)
If O(n) traversal through the list is painful, we could instead tweak
our storage to also store an end pointer (more bookkeeping to keep head
and tail pointers up-to-date, but then we always have O(1) insertion at
tail and removal at head). But typically a client won't have huge
amounts of in-flight messages (qemu-nbd defaults to 16 coroutines, and
nbdkit defaults to 16 threads, at which point any further attempts to
send more requests batch up until existing in-flight commands are
drained), so I'm not sure if the algorithmic complexity reaches the
point where it will matter.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190521/d4559b14/attachment.sig>
More information about the Libguestfs
mailing list