From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42432 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q1f3Y-0003cd-Vr for qemu-devel@nongnu.org; Mon, 21 Mar 2011 09:22:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q1f3X-0001CJ-Le for qemu-devel@nongnu.org; Mon, 21 Mar 2011 09:22:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6885) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q1f3X-0001Bj-64 for qemu-devel@nongnu.org; Mon, 21 Mar 2011 09:21:59 -0400 Message-ID: <4D8750F0.7070607@redhat.com> Date: Mon, 21 Mar 2011 15:21:52 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] block: Flush image after open References: <1299687353-20424-1-git-send-email-kwolf@redhat.com> <20110309172757.GA2884@lst.de> <4D77BB1B.9030704@codemonkey.ws> <4D874337.3040105@redhat.com> <4D874C4B.5020405@redhat.com> In-Reply-To: <4D874C4B.5020405@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Christoph Hellwig , qemu-devel@nongnu.org On 03/21/2011 03:02 PM, Kevin Wolf wrote: > Am 21.03.2011 13:23, schrieb Avi Kivity: > > On 03/09/2011 07:38 PM, Anthony Liguori wrote: > >> On 03/09/2011 11:27 AM, Christoph Hellwig wrote: > >>> On Wed, Mar 09, 2011 at 05:15:53PM +0100, Kevin Wolf wrote: > >>>> Quoting the bug report: > >>>> > >>>> qemu ensures that guest writes and qemu metadata writes hit the > >>>> disk > >>>> when necessary to prevent data corruption. However, if an image > >>>> was > >>>> in host pagecache prior to starting qemu, for example after > >>>> running > >>>> qemu-img convert, then nothing prevents writes from reaching the > >>>> disk out of order, potentially causing corruption. > >>>> > >>>> I'm not entirely sure if there is a realistic case where we would get > >>>> corruption, but it's probably a case of better safe than sorry. > >>> Except for SCSI with ordered tags (which we don't support) there are not > >>> ordering guarantees in the storage protocols, and as such the above > >>> explanation > >>> doesn't make any sense at all. > >> > >> Even if there was, a guest shouldn't be relying on the ordering of a > >> write that comes from a non-guest. > >> > >> I don't understand the failure scenario here. > > > > $ cp x.img y.img > > $ qemu -drive file=y.img,cache=writeback > > > > > > > > > > The guest may expect that any or none of its writes hit the disk, but > > that anything that it read from the disk, stays there. > > Is it true for real hardware? Consider a reboot, you could still have > some data in a volatile disk write cache if the OS that ran before the > reboot hasn't flushed it. That's if RESET doesn't flush the cache. It's probably false for fc or iscsi, but possibly true for IDE. But it can't happen for a single-boot host, or a dual boot host with no shared partitions. -- error compiling committee.c: too many arguments to function