From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57228 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ont0L-0004pT-PX for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:53:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ont0K-00045L-JW for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:53:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27041) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ont0K-00045D-Ae for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:53:28 -0400 Message-ID: <4C73C0C8.7060808@redhat.com> Date: Tue, 24 Aug 2010 14:53:28 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write_sync for metadata writes" References: <1282646430-5777-1-git-send-email-kwolf@redhat.com> <4C73AFBA.6000002@redhat.com> <4C73B364.1090900@suse.de> <4C73B6CE.4070205@redhat.com> <4C73B74B.5030105@suse.de> <4C73B87D.40303@redhat.com> <4C73B937.9050004@suse.de> <4C73BAA6.6000808@redhat.com> <4C73BC7A.9000409@redhat.com> <4C73BD71.7060507@redhat.com> In-Reply-To: <4C73BD71.7060507@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Stefan Hajnoczi , hch@lst.de, mjt@tls.msk.ru, Alexander Graf , qemu-devel@nongnu.org Am 24.08.2010 14:39, schrieb Avi Kivity: > On 08/24/2010 03:35 PM, Kevin Wolf wrote: >> >>> I don't know how bad the performance regression is, and how large the >>> integrity risk is. I'd default towards preserving integrity, but maybe >>> this situation is different. >> I have reports of installations taking like 50 min instead of 14 min. My >> own qemu-io based test goes up from 1 s to 23 s. And I think the winner >> is Michael's image conversion which went up from 30 s to 49 min. >> >> So it's not like we're talking about just some 10 or 20 percent. > > Image conversion should be done with cache=unsafe (with an fsync at the Well, should, but is not. Arguably we should improve our format drivers to make the metadata flushes less of a problem, too. But we haven't done so yet. This is why this discussion is about 0.13, not 0.14. > end to make sure a guest isn't launched with volatile data in the > cache[1]). The io test isn't a user workload. > > The 14 min -> 50 min regression is pretty bad, but I'm not sure it's bad > enough to merit risking user data. Without a disk write cache (or with a battery-backed one) cache=none is safe without any additional flushes. So yes, users need to be aware of the meaning of cache options. But they already had to be aware of it with 0.12. However, it might trap users who are not aware of it, which is why we even have this discussion. It's not an easy question. > [1] or better, when launching a guest with cache!=unsafe start with an > fsync to make sure it's on disk. Hm, that's an interesting idea, never thought of that. Might make sense. Kevin