From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TR2ho-0006XX-7f for qemu-devel@nongnu.org; Wed, 24 Oct 2012 11:17:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TR2hh-0002bi-Vf for qemu-devel@nongnu.org; Wed, 24 Oct 2012 11:17:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61603) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TR2hh-0002bK-Nh for qemu-devel@nongnu.org; Wed, 24 Oct 2012 11:17:09 -0400 Message-ID: <50880666.4070602@redhat.com> Date: Wed, 24 Oct 2012 17:16:54 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <5086728B.1010809@redhat.com> <1350990519.16343.255.camel@eboracum.office.bytemark.co.uk> <20121023150225.GB17080@jl-vm1.vm.bytemark.co.uk> <1351080994.16343.293.camel@eboracum.office.bytemark.co.uk> <5087E5BF.4090901@redhat.com> <20121024143212.GA20318@jl-vm1.vm.bytemark.co.uk> In-Reply-To: <20121024143212.GA20318@jl-vm1.vm.bytemark.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/3] nbd: Only try to send flush/discard commands if connected to the NBD server List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Kevin Wolf , qemu-devel@nongnu.org, Nicholas Thomas 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 >