Thanks. Dbench does not logically allocate new
disk space all the time, because it's a FS level benchmark
that creates file and deletes them. Therefore it also
depends on the guest FS, say, a btrfs guest FS allocates
about 1.8x space of that from EXT4, due to its COW nature.
It does cause the FS to allocate some space during about 1/3
of the test duration I think. But this does not mitigate it
too much because a FS often writes in a stride rather than
consecutively, which causes write amplification at
allocation times.
So I tested it with qemu-img convert from a 400M raw
file:
zheq-PC sdb # time ~/qemu-sync-test/bin/qemu-img
convert -f raw -t unsafe -O vdi /run/shm/rand 1.vdi
real 0m0.402s
user 0m0.206s
sys 0m0.202s
zheq-PC sdb # time ~/qemu-sync-test/bin/qemu-img
convert -f raw -t writeback -O vdi /run/shm/rand 1.vdi