From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51449 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPWPl-0006qN-PK for qemu-devel@nongnu.org; Fri, 18 Jun 2010 03:55:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPWPk-0002Cl-Hh for qemu-devel@nongnu.org; Fri, 18 Jun 2010 03:55:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25524) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPWPk-0002Cd-B9 for qemu-devel@nongnu.org; Fri, 18 Jun 2010 03:55:00 -0400 Message-ID: <4C1B2630.1090307@redhat.com> Date: Fri, 18 Jun 2010 09:54:24 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1276776211-11174-1-git-send-email-kwolf@redhat.com> <1276776211-11174-3-git-send-email-kwolf@redhat.com> <4C1A33BA.4030303@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Stefan Hajnoczi Cc: qemu-devel@nongnu.org, hch@lst.de Am 17.06.2010 21:47, schrieb Stefan Hajnoczi: > 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? This 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=writethrough or some O_DIRECT|O_DSYNC mode) in that it only hurts >> 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). qcow2 files are expected to grow, so this probably doesn't help us. At best we could try to detect if the file grows and decide if to use sync_file_range or fdatasync. Of course, it would be better to have a flag or something to include the necessary metadata, but I have no idea how it's implemented and if this is easily possible. > 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. Right, it's only growth that will get an impact. The pooint is that it's not only installation (in most cases you could even use cache=unsafe for that) but that you start to grow again after taking a snapshot - be it internal (savevm) or external (backing file). This is where it hurts. Kevin