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 >
