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 <s...@weilnetz.de> 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: > > https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Storage > > If I interpret that code correctly, blocks are normally written > asynchronously, > but changes of metadata (new block allocation) are written synchronously. > > See file VDI.cpp (function vdiBlockAllocUpdate) and VD.cpp > (vdIOIntWriteMeta). > > Stefan > >
