From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KoFFY-0004bi-GC for qemu-devel@nongnu.org; Fri, 10 Oct 2008 06:29:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KoFFT-0004XW-DB for qemu-devel@nongnu.org; Fri, 10 Oct 2008 06:29:35 -0400 Received: from [199.232.76.173] (port=37838 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KoFFT-0004XQ-5a for qemu-devel@nongnu.org; Fri, 10 Oct 2008 06:29:31 -0400 Received: from mx2.redhat.com ([66.187.237.31]:53180) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KoFFS-0004Pd-55 for qemu-devel@nongnu.org; Fri, 10 Oct 2008 06:29:30 -0400 Message-ID: <48EF2DCE.1010308@redhat.com> Date: Fri, 10 Oct 2008 12:26:22 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU References: <48EE38B9.2050106@codemonkey.ws> <48EF1D55.7060307@redhat.com> <20081010095829.GC12910@redhat.com> In-Reply-To: <20081010095829.GC12910@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org Cc: Chris Wright , Mark McLoughlin , Ryan Harper , Laurent Vivier , kvm-devel Daniel P. Berrange wrote: >> 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. > There are other data integrity solutions for developers, like backups (unlikely, I know) or -snapshot. > 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. > The fact that there are different use models for qemu implies that the default must be chosen at some higher level than qemu code itself. It might be done using /etc/qemu or ~/.qemu, or at the management interface, but there is no best setting for qemu itself. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.