Re: [Qemu-discuss] block device write caching, notifications, and QCOW2 issues

[Fam Zheng]

On Mon, 10/24 14:06, Christian Böhme wrote:
> However, we have also seen regular files, whose data, according to the
> filesystem, was modified weeks before the outage, but that nevertheless had
> garbled contents after the restart.  Such a constellation is rather 
> unexpected,
> since it is unlikely that it takes /that/ long for a well exercised journaling
> fileystem to commit its changes to persistent storage.  The "new" contents, it
> seems, is not completely random, but looks more like the result of a block
> address permutation behind the filesystem's back, as it contains fragments
> that one may find in other regular files of the same filesystem.  That is,
> the filesystem keeps thinking it addresses the same blocks it did all
> along for weeks, while the addresses themselves point to different
> blocks now.

Wild guess: can you rule out other processes (such as qemu-img) writing to the
same qcow2 WHILE QEMU is running?

> 
> Has anyone else experienced such a behaviour?  Could the block driver
> stacking employed in Qemu be the culprit, or just the Qemu QCOW2 layer?
> It looks like there is just a tad bit too much going on when it tries to
> map block addresses to regular file offsets, and this widens the window
> within which "nothing may happen" on the host.
> 
> While reading qemu(1), I also came across the notion of "write notification"
> in relation to block device write caching, where setting either  
> cache=writethrough
> or  cache=directsync  will Qemu have them generated.  Lacking further
> documentation on them, I dug through the code (
> 
> $ git status
> HEAD detached at v1.5.0
> nothing to commit, working directory clean
> 
> ), but the only thing I could discern from this was that  cache=writethrough
> or  cache=directsync  forces the Qemu block layer to issue an explicit flush
> on the block driver(s) in question immediately after every write request via
> bdrv_co_flush().  Since every request that comes in from the guest's 
> virtio_blk
> device is already acknowledged via  virtio_notify(), itself via 
> virtio_blk_req_complete(),
> the qestion remains, what "write notifications" actually are.  Anyone?

It basically means "completion of request" from guest PoV, which is the
virtio_notify() call.

Fam