From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TR0X1-0000i6-CW for qemu-devel@nongnu.org; Wed, 24 Oct 2012 08:58:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TR0Wr-0002D1-Rz for qemu-devel@nongnu.org; Wed, 24 Oct 2012 08:57:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TR0Wr-0002Ci-FV for qemu-devel@nongnu.org; Wed, 24 Oct 2012 08:57:49 -0400 Message-ID: <5087E5BF.4090901@redhat.com> Date: Wed, 24 Oct 2012 14:57:35 +0200 From: Kevin Wolf 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> In-Reply-To: <1351080994.16343.293.camel@eboracum.office.bytemark.co.uk> Content-Type: text/plain; charset=UTF-8 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: Nicholas Thomas Cc: pbonzini@redhat.com, qemu-devel@nongnu.org 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. Kevin