qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-devel@nongnu.org, Nicholas Thomas <nick@bytemark.co.uk>
Subject: Re: [Qemu-devel] [PATCH 1/3] nbd: Only try to send flush/discard commands if connected to the NBD server
Date: Wed, 24 Oct 2012 17:16:54 +0200	[thread overview]
Message-ID: <50880666.4070602@redhat.com> (raw)
In-Reply-To: <20121024143212.GA20318@jl-vm1.vm.bytemark.co.uk>

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
> 

  reply	other threads:[~2012-10-24 15:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-22 11:09 [Qemu-devel] [PATCH 0/3] NBD reconnection behaviour nick
2012-10-22 11:09 ` [Qemu-devel] [PATCH 1/3] nbd: Only try to send flush/discard commands if connected to the NBD server nick
2012-10-23 10:33   ` Kevin Wolf
2012-10-23 11:08     ` Nicholas Thomas
2012-10-23 11:26       ` Kevin Wolf
2012-10-23 15:02       ` Jamie Lokier
2012-10-24 12:16         ` Nicholas Thomas
2012-10-24 12:57           ` Kevin Wolf
2012-10-24 14:32             ` Jamie Lokier
2012-10-24 15:16               ` Paolo Bonzini [this message]
2012-10-25  6:36               ` Kevin Wolf
2012-10-25 17:09                 ` Jamie Lokier
2012-10-26  7:59                   ` Kevin Wolf
2012-10-24 14:03           ` Paolo Bonzini
2012-10-24 14:10             ` Paolo Bonzini
2012-10-24 14:12               ` Nicholas Thomas
2012-10-22 11:09 ` [Qemu-devel] [PATCH 2/3] nbd: Explicitly disconnect and fail inflight I/O requests on error, then reconnect next I/O request nick
2012-10-23 10:40   ` Kevin Wolf
2012-10-24 14:31   ` Paolo Bonzini
2012-10-22 11:09 ` [Qemu-devel] [PATCH 3/3] nbd: Move reconnection attempts from each new I/O request to a 5-second timer nick

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50880666.4070602@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=jamie@shareable.org \
    --cc=kwolf@redhat.com \
    --cc=nick@bytemark.co.uk \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).