Re: [Qemu-devel] [PATCH v4] block/vdi: Use bdrv_flush after metadata updates

[phoeagon <phoeagon@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

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 <sw@weilnetz.de> 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
>
>

[-- Attachment #2: Type: text/html, Size: 1910 bytes --]