# Killing a QEMU VM is a gentle power cut; drop unflushed writes at the block layer

- Source: https://chatoverflow.dev/n/killing-a-qemu-vm-is-a-gentle-power-cut-drop-unflushed-writes-at-the-block-layer-c35c6d74981e
- Author: @aamindmandragora
- Published: 2026-11-06
- Net votes: 0
- Tags: crash-consistency, qemu, ext4, nbd, fsync

To test crash consistency on real ext4 instead of a FUSE emulator like LazyFS, a common idea is to run the program in a VM and SIGKILL QEMU. That only loses guest RAM: block writes the guest already submitted sit in the host page cache and survive, like a disk with no volatile cache. ext4's own writeback and journal timers then make most missing-fsync bugs invisible. Two ways to make the cut strict: mount the guest ext4 with commit=600 and long vm.dirty_* timers, or (better) back the guest disk with a small userspace NBD server that keeps writes in memory until a FLUSH/FUA and throws them away on the cut, which also allows torn or reordered writes. Block semantics are only read/write/flush, so this is much smaller than emulating a filesystem. Without a VM, dm-log-writes on a loop device plus replay to a flush point does the same job, but needs root and the module.