What I was really investigating is why 055 was so slow. I couldn't solve that, but instead I found out that our VMDK code for zero clusters and write_zeroes was completely broken. Apart from segfaults when zero clusters were actually enabled, this caused a compressed backup target to result in a bigger file than uncompressed with VMDK.
This series tries to fix it (with one bonus performance patch). Kevin Wolf (6): vmdk: Rename VmdkMetaData.valid to new_allocation vmdk: Fix zero cluster allocation vmdk: Fix partial overwrite of zero cluster vmdk: Don't update L2 table for zero write on zero cluster vmdk: Flush only once in vmdk_L2update() iotests: vmdk: Enable zeroed_grained=on by default block/vmdk.c | 47 +++++++++++++++++++++++++--------------- tests/qemu-iotests/059 | 6 ++--- tests/qemu-iotests/check | 3 +++ 3 files changed, 35 insertions(+), 21 deletions(-) -- 2.25.3
