[Top][All Lists]

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

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

From: phoeagon
Subject: Re: [Qemu-devel] [PATCH v4] block/vdi: Use bdrv_flush after metadata updates
Date: Sun, 10 May 2015 17:14:28 +0000

I'm not familiar with the VirtualBox code base, but looks like "vdIOIntWriteMeta" can work both synchronously & asynchronously, and "vdiBlockAllocUpdate" looks async to me. Frankly, skimming through the code for 5 min doesn't enlighten me too much on its detailed implementation, but looks like at least Virtualbox has VDI-repair that fixes block leaks relatively easily. 

I would agree that a more complete implementation on VDI-check-and-repair might be better in this particular situation. I'm not sure if there are other cases where flush after metadata update might be better, but doesn't look like qemu-img auto repair is coming to other writable image formats in the near future.

Also, I think that memory exhaustion and consequent page cache eviction are not too uncommon on computers not originally designed to run VMs. Many laptops are still trapped with 4GB memory and there seem to widespread instructions on tuning down the swappiness to favor page cache drops than swapping out memory, all of which adds to the odds of metadata inconsistency.

On Mon, May 11, 2015 at 12:26 AM Stefan Weil <address@hidden> wrote:
Am 10.05.2015 um 18:10 schrieb Paolo Bonzini:
> On 10/05/2015 18:02, Stefan Weil wrote:
>>> Since the default qemu-img convert case isn't slowed down, I
>>> would think that correctness trumps performance.  Nevertheless,
>>> it's a huge difference.
>> I doubt that the convert case isn't slowed down.
> The *default* convert case isn't slowed down because "qemu-img convert"
> defaults to the "unsafe" cache mode.
> The *non-default* convert case with flushes was slowed down indeed: 2x
> in total (if you include the final flush done by bdrv_close), and 10x if
> you only consider the sequential write part of convert.
> Paolo

For those who might be interested:

The relevant GPL source code from VirtualBox is available here:


If I interpret that code correctly, blocks are normally written
but changes of metadata (new block allocation) are written synchronously.

See file VDI.cpp (function vdiBlockAllocUpdate) and VD.cpp


reply via email to

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