From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45701) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrTvI-0002YW-LV for qemu-devel@nongnu.org; Sun, 10 May 2015 12:17:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YrTvE-0000WG-70 for qemu-devel@nongnu.org; Sun, 10 May 2015 12:17:45 -0400 Message-ID: <554F8117.1070800@weilnetz.de> Date: Sun, 10 May 2015 18:02:31 +0200 From: Stefan Weil MIME-Version: 1.0 References: <1430971496-32659-1-git-send-email-phoeagon@gmail.com> <1431011818-15822-1-git-send-email-phoeagon@gmail.com> <554CB6C6.3060809@redhat.com> <20150508135512.GJ4318@noname.redhat.com> <554D2A03.3080201@weilnetz.de> <554F72E6.5060001@redhat.com> In-Reply-To: <554F72E6.5060001@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4] block/vdi: Use bdrv_flush after metadata updates List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , phoeagon , Kevin Wolf , Max Reitz Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org Am 10.05.2015 um 17:01 schrieb Paolo Bonzini: > > On 09/05/2015 05:54, phoeagon wrote: >> zheq-PC sdb # time ~/qemu-sync-test/bin/qemu-img convert -f raw -t writeback -O vdi /run/shm/rand 1.vdi >> >> real0m8.678s >> user0m0.169s >> sys0m0.500s >> >> zheq-PC sdb # time qemu-img convert -f raw -t writeback -O vdi /run/shm/rand 1.vdi >> real0m4.320s >> user0m0.148s >> sys0m0.471s > This means that 3.83 seconds are spent when bdrv_close() calls > bdrv_flush(). That's the only difference between writeback > and unsafe in qemu-img convert. > > The remaining part of the time (4.85 seconds instead of 0.49 > seconds) means that, at least on your hardware, sequential writes > to unallocated space become 10 times slower with your patch. > > Since the default qemu-img convert case isn't slowed down, I > would think that correctness trumps performance. Nevertheless, > it's a huge difference. > > Paolo I doubt that the convert case isn't slowed down. Writing to a tmpfs as it was obviously done for the test is not a typical use case. With real hard disks I expect a significant slowdown. Stefan