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
