From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37607 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPL3u-0006cq-LU for qemu-devel@nongnu.org; Thu, 17 Jun 2010 15:47:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPL3c-0002bh-OK for qemu-devel@nongnu.org; Thu, 17 Jun 2010 15:47:25 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:51845) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPL3c-0002bW-Ln for qemu-devel@nongnu.org; Thu, 17 Jun 2010 15:47:24 -0400 Received: by vws5 with SMTP id 5so893494vws.4 for ; Thu, 17 Jun 2010 12:47:23 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4C1A33BA.4030303@redhat.com> References: <1276776211-11174-1-git-send-email-kwolf@redhat.com> <1276776211-11174-3-git-send-email-kwolf@redhat.com> <4C1A33BA.4030303@redhat.com> Date: Thu, 17 Jun 2010 20:47:07 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [RFC][PATCH 2/2] qcow2: Use bdrv_(p)write_sync for metadata writes List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, hch@lst.de On Thu, Jun 17, 2010 at 3:39 PM, Kevin Wolf wrote: > Am 17.06.2010 16:19, schrieb Stefan Hajnoczi: >> On Thu, Jun 17, 2010 at 1:03 PM, Kevin Wolf wrote: >>> Use bdrv_(p)write_sync to ensure metadata integrity in case of a crash. >> >> Any performance numbers? =A0This change is necessary for correctness but >> I wonder what the performance impact is for users. > > No numbers yet, but as you say we need to do it anyway. It should > definitely be better than any other option that I can think of > (cache=3Dwritethrough or some O_DIRECT|O_DSYNC mode) in that it only hurt= s > performance when metadata is actually changed. As long as we only write > guest data, there is no difference. > > Making it a barrier instead of a flush would probably be better, have > you already had a look at this since we talked about it? No I haven't seen a userspace barrier solution. I'm not actively working on that at the moment but am keeping an eye out for solutions. I'm not sure what to make of sync_file_range(2), the man page suggests it cannot be relied on since only already allocated blocks will be flushed appropriately. Filesystem metadata changes are not flushed, which is especially problematic for copy-on-write filesystems (according to the man page). Thinking about the performance more, I predict that guest OS installations will slow down but day-to-day usage (especially modifying already allocated blocks) will be alright for the reasons you mentioned. Stefan