From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpH96-00010h-W2 for qemu-devel@nongnu.org; Mon, 13 Oct 2008 02:43:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpH96-00010V-5X for qemu-devel@nongnu.org; Mon, 13 Oct 2008 02:43:12 -0400 Received: from [199.232.76.173] (port=49831 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpH96-00010S-2N for qemu-devel@nongnu.org; Mon, 13 Oct 2008 02:43:12 -0400 Received: from mx20.gnu.org ([199.232.41.8]:42306) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KpH95-0002i4-EP for qemu-devel@nongnu.org; Mon, 13 Oct 2008 02:43:11 -0400 Received: from hall.aurel32.net ([88.191.82.174]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KpH94-0000hg-8L for qemu-devel@nongnu.org; Mon, 13 Oct 2008 02:43:10 -0400 Message-ID: <48F2EDEB.5040906@aurel32.net> Date: Mon, 13 Oct 2008 08:42:51 +0200 From: Aurelien Jarno MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU References: <48EE38B9.2050106@codemonkey.ws> <48EF1D55.7060307@redhat.com> <48F0E83E.2000907@redhat.com> <48F10DFD.40505@codemonkey.ws> <48F14814.7000805@redhat.com> <48F239DB.6050302@codemonkey.ws> <48F295F0.3020105@redhat.com> <48F2A294.4020303@codemonkey.ws> <48F2ADD9.9000804@redhat.com> In-Reply-To: <48F2ADD9.9000804@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 , Laurent Vivier , kvm-devel Mark Wagner a écrit : > Anthony Liguori wrote: >> Mark Wagner wrote: >>> If you stopped and listened to yourself, you'd see that you are making >>> my point... >>> >>> AFAIK, QEMU is neither designed nor intended to be an Enterprise >>> Storage Array, >>> I thought this group is designing a virtualization layer. However, >>> the persistent >>> argument is that since Enterprise Storage products will often >>> acknowledge a write >>> before the data is actually on the disk, its OK for QEMU to do the same. >> I think you're a little lost in this thread. We're going to have QEMU >> only acknowledge writes when they complete. I've already sent out a >> patch. Just waiting a couple days to let everyone give their input. >> > Actually, I'm just don't being clear enough in trying to point out that I > don't think just setting a default value for "cache" goes far enough. My > argument has nothing to do with the default value. It has to do with what the > right thing to do is in specific situations regardless of the value of the > cache setting. > > My point is that if a file is opened in the guest with the O_DIRECT (or O_DSYNC) > then QEMU *must* honor that regardless of whatever value the current value of > "cache" is. > > So, if the system admin for the host decides to set cache=on and something > in the guest opens a file with O_DIRECT, I feel that it is a violation > of the system call for the host to cache the write in its local cache w/o > sending it immediately to the storage subsystem. It must get an ACK from > the storage subsystem before it can return to the guest in order to preserve > the guarantee. > > So, if your proposed default value for the cache is in effect, then O_DSYNC > should provide the write-thru required by the guests use of O_DIRECT on the > writes. However, if the default cache value is not used and its set to > cache=on, and if the guest is using O_DIRECT or O_DSYNC, I feel there are > issues that need to be addressed. > Everybody agrees that we should support data integrity *by default*. But please admit that some persons have different needs than yours, and actually *want* to lie to the guest. We should propose such and option, with a *big warning*. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net