From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KaWp1-0006BC-Ab for qemu-devel@nongnu.org; Tue, 02 Sep 2008 10:25:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KaWoz-0006Ae-F8 for qemu-devel@nongnu.org; Tue, 02 Sep 2008 10:25:30 -0400 Received: from [199.232.76.173] (port=35956 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KaWoz-0006Ab-7S for qemu-devel@nongnu.org; Tue, 02 Sep 2008 10:25:29 -0400 Received: from pasmtpb.tele.dk ([80.160.77.98]:58948) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KaWoz-0005pY-Ao for qemu-devel@nongnu.org; Tue, 02 Sep 2008 10:25:29 -0400 Received: from kernel.dk (brick.kernel.dk [93.163.65.50]) by pasmtpB.tele.dk (Postfix) with ESMTP id 082B8E307B6 for ; Tue, 2 Sep 2008 16:25:26 +0200 (CEST) Date: Tue, 2 Sep 2008 16:25:24 +0200 From: Jens Axboe Subject: Re: [Qemu-devel] [PATCH] bdrv_aio_flush Message-ID: <20080902142523.GH20055@kernel.dk> References: <20080829133736.GH24884@duo.random> <18619.53638.814196.657141@mariner.uk.xensource.com> <20080901122521.GG25764@duo.random> <18621.6888.630519.634369@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18621.6888.630519.634369@mariner.uk.xensource.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Tue, Sep 02 2008, Ian Jackson wrote: > Andrea Arcangeli writes ("Re: [Qemu-devel] [PATCH] bdrv_aio_flush"): > > In case you meant fsync is just fine, Linux will use the > > WIN_FLUSH_CACHE/WIN_FLUSH_CACHE_EXT see > > idedisk_prepare_flush: > > > > if (barrier) { > > ordered = QUEUE_ORDERED_DRAIN_FLUSH; > > prep_fn = idedisk_prepare_flush; > > } > > I'm not sure I follow but I'm not familiar with the relevant Linux > code. Do you mean that Linux does this > > submit IO 1 to device > submit flush to device > collect IO 1 completion > collect flush completion > > and then expects IO 1 to be on disk ? Given that this case refers to PATA/SATA and that you can't queue the flush operation, it looks something like: submit IO 1 to device IO 1 completes submit flush flush completes and at this point, flush completion either ends in error (in which case we can't rely on IO 1 being safely stored), or it suceeds and Linux then expects IO 1 to be on disk. If it isn't, then the device is broken (as simple as that). > If this is a documented behaviour of the controller or device we're > emulating then I think the qemu emulation (hw/scsi-disk.c or whatever) > should do an aio_flush barrier before aio_fsync. Certainly it is, when the flush command returns, all dirty drive cache must be safely on platter. > What spec should I be referring to ? ata spec, see t13.org > Perhaps I'm naive but I would expect the device interface to look more > like the kernel syscall interface, whose specification text (in SuSv3) > I analysed in April in > http://lists.nongnu.org/archive/html/qemu-devel/2008-04/msg00046.html > > Ian. > > -- Jens Axboe