Re: [Qemu-devel] [PATCH 1/3] nbd: Only try to send flush/discard commands if connected to the NBD server

[Paolo Bonzini <pbonzini@redhat.com>]

Il 24/10/2012 16:32, Jamie Lokier ha scritto:
> Kevin Wolf wrote:
>> Am 24.10.2012 14:16, schrieb Nicholas Thomas:
>>> On Tue, 2012-10-23 at 16:02 +0100, Jamie Lokier wrote:
>>>> Since the I/O _order_ before, and sometimes after, flush, is important
>>>> for data integrity, this needs to be maintained when I/Os are queued in
>>>> the disconnected state -- including those which were inflight at the
>>>> time disconnect was detected and then retried on reconnect.
>>>
>>> Hmm, discussing this on IRC I was told that it wasn't necessary to
>>> preserve order - although I forget the fine detail. Depending on the
>>> implementation of qemu's coroutine mutexes, operations may not actually
>>> be performed in order right now - it's not too easy to work out what's
>>> happening.
>>
>> It's possible to reorder, but it must be consistent with the order in
>> which completion is signalled to the guest. The semantics of flush is
>> that at the point that the flush completes, all writes to the disk that
>> already have completed successfully are stable. It doesn't say anything
>> about writes that are still in flight, they may or may not be flushed to
>> disk.
> 
> I admit I wasn't thinking clearly how much ordering NBD actually
> guarantees (or if there's ordering the guest depends on implicitly
> even if it's not guaranteed in specification),

Here NBD is used just as a transport on the host and totally invisible
to the guest.  So NBD pretty much has to implement whatever ordering
guarantees the guest needs.

> E.g. if every device emulation waited for all outstanding writes to
> complete before sending a flush, then it wouldn't matter how the
> backend reordered its requests, even getting the completions out of
> order.

The NBD implementation in QEMU (which Nick is using) is completely
asynchronous.

Paolo

> Is that relationship documented (and conformed to)?
> 
> -- Jamie
>