From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KoEp6-0006EE-Ti for qemu-devel@nongnu.org; Fri, 10 Oct 2008 06:02:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KoEp5-0006Dz-Oz for qemu-devel@nongnu.org; Fri, 10 Oct 2008 06:02:16 -0400 Received: from [199.232.76.173] (port=59883 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KoEp5-0006Dw-Cn for qemu-devel@nongnu.org; Fri, 10 Oct 2008 06:02:15 -0400 Received: from mx1.redhat.com ([66.187.233.31]:60202) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KoEp4-0006Jx-Qy for qemu-devel@nongnu.org; Fri, 10 Oct 2008 06:02:15 -0400 Date: Fri, 10 Oct 2008 10:58:29 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU Message-ID: <20081010095829.GC12910@redhat.com> References: <48EE38B9.2050106@codemonkey.ws> <48EF1D55.7060307@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48EF1D55.7060307@redhat.com> Reply-To: "Daniel P. Berrange" , 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 On Fri, Oct 10, 2008 at 11:16:05AM +0200, Avi Kivity wrote: > Anthony Liguori wrote: > > [O_DSYNC, O_DIRECT, and 0] > > > > >Thoughts? > > There are (at least) three usage models for qemu: > > - OS development tool > - casual or client-side virtualization > - server partitioning > > The last two uses are almost always in conjunction with a hypervisor. > > When using qemu as an OS development tool, data integrity is not very > important. On the other hand, performance and caching are, especially > as the guest is likely to be restarted multiple times so the guest page > cache is of limited value. For this use model the current default > (write back cache) is fine. It is a myth that developers dont' care about data consistency / crash safety. I've lost countless guest VMs to corruption when my host OS crashed & its just a waste of my time. Given the choice between likely-to-corrupt and not-likely-to-corrupt, even developers will want the latter. > The 'causal virtualization' use is when the user has a full native > desktop, and is also running another operating system. In this case, > the host page cache is likely to be larger than the guest page cache. > Data integrity is important, so write-back is out of the picture. I > guess for this use case O_DSYNC is preferred though O_DIRECT might not > be significantly slower for long-running guests. This is because reads > are unlikely to be cached and writes will not benefit much from the host > pagecache. > > For server partitioning, data integrity and performance are critical. > The host page cache is significantly smaller than the guest page cache; > if you have spare memory, give it to your guests. O_DIRECT is > practically mandataed here; the host page cache does nothing except to > impose an additional copy. > > Given the rather small difference between O_DSYNC and O_DIRECT, I favor > not adding O_DSYNC as it will add only marginal value. > > Regarding choosing the default value, I think we should change the > default to be safe, that is O_DIRECT. If that is regarded as too > radical, the default should be O_DSYNC with options to change it to > O_DIRECT or writeback. Note that some disk formats will need updating > like qcow2 if they are not to have abyssal performance. Absoutely agree that the default should be safe. I don't have enough knowledge to say whether O_DIRECT/O_DSYNC is best - which also implies we should choose the best setting by default, because we can't expect users to know the tradeoffs either. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|