From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KutA0-00008P-Va for qemu-devel@nongnu.org; Tue, 28 Oct 2008 14:19:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kut9y-00006F-Av for qemu-devel@nongnu.org; Tue, 28 Oct 2008 14:19:20 -0400 Received: from [199.232.76.173] (port=51266 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kut9y-000068-2Q for qemu-devel@nongnu.org; Tue, 28 Oct 2008 14:19:18 -0400 Received: from mail2.shareable.org ([80.68.89.115]:35229) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kut9x-0007Lk-SJ for qemu-devel@nongnu.org; Tue, 28 Oct 2008 14:19:18 -0400 Date: Tue, 28 Oct 2008 18:19:10 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU Message-ID: <20081028181910.GA18003@shareable.org> References: <48EE38B9.2050106@codemonkey.ws> <18695.19759.210510.580450@mariner.uk.xensource.com> <49074FD6.9060408@codemonkey.ws> <18695.20706.684682.248675@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18695.20706.684682.248675@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 Cc: Chris Wright , Mark McLoughlin , Ryan Harper , kvm-devel , Laurent Vivier Ian Jackson wrote: > > We've switched to always use O_DSYNC by default. There was a very > > long thread about it including benchmarks. With the right posix-aio > > tuning, we can use O_DSYNC without hurting performance*. > > Right. > > With the change in my tree, the guest can turn on the use of the > host's buffer cache for writes (ie, turn off the use of O_DSYNC), > using the appropriate cache control features in the IDE controller > (and have write barriers with the FLUSH CACHE command). I think this is a good idea in principle, but it needs to be overridable by command line and monitor controls. There are a number of guests and usages where you'd want to override it. These come to mind: - Enable host write caching even though the guest turns off IDE caching, because you're testing something and speed is more important than what the guest requests, and you don't want to or can't change the guest. - Disable host write caching even though the guest turns on IDE caching, because you know the guest enables the IDE cache for speed and does not flush the IDE cache for integrity (e.g. some old Linux or Windows?), and you don't want to or can't change the guest. - Disable host read and write caching with O_DIRECT, even though the guest turns on IDE caching, because you want to emulate (roughly) a real disk's performance characteristics. - Disable host read and write caching with O_DIRECT because you don't have spare RAM after the guests have used it. Note that O_DIRECT is not strictly "less caching" than O_DSYNC. Guest IDE FLUSH CACHE commands become host fsync/fdatasync calls. On some Linux hosts, O_DSYNC + fsync will result in a _host_ IDE FLUSH CACHE, when O_DIRECT + fsync will not. -- Jamie