From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58399 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Onsmd-0005wY-Sh for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:39:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Onsmc-0002Hn-KK for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:39:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15465) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Onsmc-0002Hj-DP for qemu-devel@nongnu.org; Tue, 24 Aug 2010 08:39:18 -0400 Message-ID: <4C73BD71.7060507@redhat.com> Date: Tue, 24 Aug 2010 15:39:13 +0300 From: Avi Kivity 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> In-Reply-To: <4C73BC7A.9000409@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Stefan Hajnoczi , hch@lst.de, mjt@tls.msk.ru, Alexander Graf , qemu-devel@nongnu.org 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 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. [1] or better, when launching a guest with cache!=unsafe start with an fsync to make sure it's on disk. -- error compiling committee.c: too many arguments to function