From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: JFYI: ext4 bug triggerable by kvm Date: Tue, 17 Aug 2010 09:57:26 -0500 Message-ID: <4C6AA356.4030303@codemonkey.ws> References: <4C694E7D.3060600@codemonkey.ws> <20100816184237.GA16579@infradead.org> <4C69A0C4.2080102@codemonkey.ws> <20100817090755.GA11110@infradead.org> <4C6A86E4.9080600@codemonkey.ws> <20100817130702.GA16635@infradead.org> <4C6A9AB5.6050404@codemonkey.ws> <20100817142808.GA22412@infradead.org> <4C6A9F4F.8040209@msgid.tls.msk.ru> <4C6AA061.80704@codemonkey.ws> <20100817144651.GB10280@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Tokarev , KVM list , Kevin Wolf To: Christoph Hellwig Return-path: Received: from mail-gw0-f46.google.com ([74.125.83.46]:57799 "EHLO mail-gw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751493Ab0HQO53 (ORCPT ); Tue, 17 Aug 2010 10:57:29 -0400 Received: by gwj17 with SMTP id 17so1546186gwj.19 for ; Tue, 17 Aug 2010 07:57:28 -0700 (PDT) In-Reply-To: <20100817144651.GB10280@infradead.org> Sender: kvm-owner@vger.kernel.org List-ID: On 08/17/2010 09:46 AM, Christoph Hellwig wrote: > On Tue, Aug 17, 2010 at 09:44:49AM -0500, Anthony Liguori wrote: > >> I think the real issue is we're mixing host configuration with guest >> visible state. >> > The last time I proposed to decouple the two you and Avi were heavily > opposed to it.. > > >> With O_SYNC, we're causing cache=writethrough to do writethrough >> through two layers of the storage heirarchy. I don't think that's >> necessary or desirable though. >> > It's absolutely nessecary if we tell the guest that we do not have > a volatile write cache. Which is the only good reason to use > data=writethrough anyway - except for dealing with old guests that > can't handle volatile writecache it's an absolutely stupid mode of > operation. > You can lose an awful lot of data with cache=writeback because the host page cache is volatile. In a perfect world, this would only be non-critical data because everyone would be using fsync() properly but 1) even non-critical data is important when there's a lot of it 2) we don't live in a perfect world. The fact of the matter is, there is a huge amount of crappy filesystems and applications today that don't submit barriers appropriately. We make the situation much worse with virtualization because of the shear size of the cache we introduce. Regards, Anthony Liguori