On 09/05/2015 05:54, phoeagon wrote:
zheq-PC sdb # time ~/qemu-sync-test/bin/qemu-img convert -f raw -t writeback
-O vdi /run/shm/rand 1.vdi
real0m8.678s
user0m0.169s
sys0m0.500s
zheq-PC sdb # time qemu-img convert -f raw -t writeback -O vdi /run/shm/rand
1.vdi
real0m4.320s
Just for clarity, I was not writing to tmpfs. I was READING from tmpfs. I
was writing to a path named 'sdb' (as you see in the prompt) which is a
btrfs on an SSD Drive. I don't have an HDD to test on though.
On Mon, May 11, 2015 at 12:02 AM Stefan Weil s...@weilnetz.de wrote:
Am 10.05.2015 um
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
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
BTW, how do you usually measure the time to install a Linux distro within?
Most distros ISOs do NOT have unattended installation ISOs in place. (True
I can bake my own ISOs for this...) But do you have any ISOs made ready for
this purpose?
On Sat, May 9, 2015 at 11:54 AM phoeagon
In reference to b0ad5a45...078a458e, metadata writes to
qcow2/cow/qcow/vpc/vmdk are all synced prior to succeeding writes.
Only when write is successful that bdrv_flush is called.
Signed-off-by: Zhe Qiu phoea...@gmail.com
---
block/vdi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
