From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrTjV-00087E-5f for qemu-devel@nongnu.org; Sun, 10 May 2015 12:05:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YrTjT-00057e-U2 for qemu-devel@nongnu.org; Sun, 10 May 2015 12:05:37 -0400 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> <554F8117.1070800@weilnetz.de> In-Reply-To: <554F8117.1070800@weilnetz.de> From: phoeagon Date: Sun, 10 May 2015 16:05:33 +0000 Message-ID: Content-Type: multipart/alternative; boundary=001a113eb3186707630515bc6eb7 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: Stefan Weil , Paolo Bonzini , Kevin Wolf , Max Reitz Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org --001a113eb3186707630515bc6eb7 Content-Type: text/plain; charset=UTF-8 Just for clarity, I was not writing to tmpfs. I was READING from tmpfs. I was writing to a path named 'sdb' (as you see in the prompt) which is a btrfs on an SSD Drive. I don't have an HDD to test on though. On Mon, May 11, 2015 at 12:02 AM Stefan Weil wrote: > 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 > > --001a113eb3186707630515bc6eb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just for clarity, I was not writing to tmpfs. I was READIN= G from tmpfs. I was writing to a path named 'sdb' (as you see in th= e prompt) which is a btrfs on an SSD Drive. I don't have an HDD to test= on though.

On Mon, May 11, 2015 at= 12:02 AM Stefan Weil <sw@weilnetz.de<= /a>> wrote:
Am 10.05.2015 um 17:01 sch= rieb 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 /ru= n/shm/rand 1.vdi
>> real0m4.320s
>> user0m0.148s
>> sys0m0.471s
> This means that 3.83 seconds are spent when bdrv_close() calls
> bdrv_flush().=C2=A0 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.=C2=A0 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

--001a113eb3186707630515bc6eb7--