From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH, RFC] virtio_blk: add cache flush command Date: Mon, 11 May 2009 19:49:37 +0300 Message-ID: <4A085721.2050005@redhat.com> References: <20090511083908.GB20082@lst.de> <4A083B7C.1000703@codemonkey.ws> <20090511154046.GA4226@lst.de> <4A08482E.30100@redhat.com> <20090511162810.GA6027@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Rusty Russell , kvm@vger.kernel.org To: Christoph Hellwig Return-path: Received: from mx2.redhat.com ([66.187.237.31]:37851 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750943AbZEKQuP (ORCPT ); Mon, 11 May 2009 12:50:15 -0400 In-Reply-To: <20090511162810.GA6027@lst.de> Sender: kvm-owner@vger.kernel.org List-ID: Christoph Hellwig wrote: > 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. > Maybe we should add a fourth cache= mode then. But cache=writeback+fsync doesn't correspond to any real world drive; in the real world you're limited to power failures and a few megabytes of cache (typically less), cache=writeback+fsync can lose hundreds of megabytes due to power loss or software failure. Oh, and cache=writeback+fsync doesn't work on qcow2, unless we add fsync after metadata updates. >> 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. > Yeah. And maybe one day push the barrier into the kernel. > (Or maybe ext3 actually is stupid enough to flush the whole fs even for > that case Sigh. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.