[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH v3] block/vdi: Use bdrv_flush after

From: phoeagon
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v3] block/vdi: Use bdrv_flush after metadata updates
Date: Fri, 08 May 2015 12:56:30 +0000

I tested it on host-btrfs, guest-ext4, (connected to guest via virtualized IDE) with 1G VDI image, testing with "dbench 10":

Writeback: 39.4852M/s 326.812ms
Unsafe: 432.72M/s 1029.313ms

Writeback: 39.1884M/s 311.383ms
Unsafe: 413.592M/s 280.951ms

Although I hear that dbench is not a good I/O benchmark (and iozone is just a little too much hassle) but I'm pretty sure the difference, if any, is within fluctuation in this case. Under my setting even a raw "dd of=/dev/sdb" (from within a VM) doesn't have higher than 20M/s even without this extra write barrier in the proposed patch.

So although what described above is not comprehensive (you can probably extract the most overhead by deliberately O_DIRECT writing at 1M stride, 512K each, no application level sync in "writeback" cache mode of VDI, what originally mostly resides in host page cache now must be flushed to hard disk, probably in an inconvenient order if host FS highly fragmented), I doubt consecutive raw writes cover several Megabytes or guest-FS based workload would see much performance overhead after introducing this extra sync.

On Fri, May 8, 2015 at 8:02 PM Kevin Wolf <address@hidden> wrote:
Am 08.05.2015 um 13:50 hat phoeagon geschrieben:
> In case of correctness, lacking a sync here does not introduce data corruption
> I can think of. But this reduces the volatile window during which the metadata
> changes are NOT guaranteed on disk. Without a barrier, in case of power loss
> you may end up with the bitmap changes on disk and not the header block, or
> vice versa. Neither introduces data corruption directly, but since VDI doesn't
> have proper fix mechanism for qemu-img, once the leak is introduced you have to
> "convert" to fix it, consuming a long time if the disk is large.

This is true. I'm not sure how big a problem this is in practice,

> This patch does not fix the issue entirely, and it does not substitute for
> proper check-and-fix implementation. But this should bring about minor
> performance degradation (only 1 extra sync per allocation) but greatly reduces
> the metadata inconsistency window.

Did you benchmark this? From the past experience with flushes in qemu
block drivers, one sync per allocation certainly doesn't sound "minor".

What could possibly save us from the worst is that VDI has a relatively
large block size (or rather, that we don't support images with different
block sizes).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]