From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH, RFC] virtio_blk: add cache flush command Date: Mon, 11 May 2009 18:28:10 +0200 Message-ID: <20090511162810.GA6027@lst.de> References: <20090511083908.GB20082@lst.de> <4A083B7C.1000703@codemonkey.ws> <20090511154046.GA4226@lst.de> <4A08482E.30100@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , Anthony Liguori , Rusty Russell , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from verein.lst.de ([213.95.11.210]:34933 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751678AbZEKQ2a (ORCPT ); Mon, 11 May 2009 12:28:30 -0400 Content-Disposition: inline In-Reply-To: <4A08482E.30100@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, May 11, 2009 at 06:45:50PM +0300, Avi Kivity wrote: > >Right now it's fsync. By the time I'll submit the backend change it > >will still be fsync, but at least called from the posix-aio-compat > >thread pool. > > > > I think if we have cache=writeback we should ignore this. It's only needed for cache=writeback, because without that there is no reason to flush a write cache. > For cache=none and cache=writethrough we don't really need fsync, but we > do need to flush the inflight commands. What we do need for those modes is the basic barrier support because we can currently re-order requests. The next version of my patch will implement a barriers without cache flush mode, although I don't think a fdatasync without any outstanding dirty data should cause problems. (Or maybe ext3 actually is stupid enough to flush the whole fs even for that case)