Am 30.04.2020 um 15:30 hat Kevin Wolf geschrieben: > 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).
Thanks for the review, fixed up the commit messages and applied. If you were curious about the VMDK terminology, I looked it up and the basic terms translate to qcow2 like this: * grain directory = L1 table * grain table = L2 table * grain = cluster "zeroed-grain GTE (grain table entry)" is the exact term used in the VMDK spec for what we would call a zero cluster in qcow2. Kevin
