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:54:07 -0500 Message-ID: <4C6AA28F.1000605@codemonkey.ws> References: <4C694483.5010903@msgid.tls.msk.ru> <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> <4C6A9F13.9030104@codemonkey.ws> <20100817144507.GA10280@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-gx0-f174.google.com ([209.85.161.174]:36566 "EHLO mail-gx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751985Ab0HQOyM (ORCPT ); Tue, 17 Aug 2010 10:54:12 -0400 Received: by gxk23 with SMTP id 23so2523446gxk.19 for ; Tue, 17 Aug 2010 07:54:11 -0700 (PDT) In-Reply-To: <20100817144507.GA10280@infradead.org> Sender: kvm-owner@vger.kernel.org List-ID: On 08/17/2010 09:45 AM, Christoph Hellwig wrote: > On Tue, Aug 17, 2010 at 09:39:15AM -0500, Anthony Liguori wrote: > >> The type of cache we present to the guest only should relate to how >> the hypervisor caches the storage. It should be independent of how >> data is cached by the disk. >> > It is. > > >> There can be many levels of caching in a storage hierarchy and each >> hierarchy cached independently of the next level. >> >> If the user has a disk with a writeback cache, if we expose a >> writethrough cache to the guest, it's not our responsibility to make >> sure that we break through the writeback cache on the disk. >> > The users doesn't know or have to care about the caching. The > users uses O_SYNC/fsync to tell it wants data on disk, and it's the > operating systems job to make that happen. The situation with qemu > is the same - if we tell the guest that we do not have a volatile write > cache that needs explicit management the guest can rely on the fact > that it does not have to do manual cache management. > This is simply unrealistic. O_SYNC might force data to be on a platter when using a directly attached disk but many NAS's actually do writeback caching and relying on having an UPS to preserve data integrity. There's really no way in the general case to ensure that data is actually on a platter once you've involved a complex storage setup or you assume FUA Let me put it another way. If an admin knows the disks on a machine have battery backed cache, he's likely to leave writeback caching enabled. We are currently giving the admin two choices with QEMU, either ignore the fact that the disk is battery backed and do write through caching of the disk or do writeback caching in the host which expands the disk cache from something very small and non-volatile (the on-disk cache) to something very large and volatile (the page cache). To make the page cache non-volatile, you would need to have an UPS for the hypervisor with enough power to flush the page cache. So basically, we're not presenting a model that makes sensible use of reliable disks. cache=none does the right thing here but doesn't benefit from the host's page cache for reads. This is really the missing behavior. Regards, Anthony Liguori