On 25.07.19 17:55, Max Reitz wrote: > Hi, > > 69f47505ee66afaa513305de0c1895a224e52c45 changed block_status so that it > would only go down to the protocol layer if the format layer returned > BDRV_BLOCK_RECURSE, thus indicating that it has no sufficient > information whether a given range in the image is zero or not. > Generally, this is because the image is preallocated and thus all ranges > appear as zeroes. > > However, it only implemented this preallocation detection for qcow2. > There are more formats that support preallocation, though: vdi, vhdx, > vmdk, vpc. (Funny how they all start with “v”.) > > For vdi, vmdk, and vpc, the fix is rather simple, because they really > have different subformats depending on whether an image is preallocated > or not. This makes the check very simple. > > vhdx is more like qcow2, where after the image has been created, it > isn’t clear whether it’s been preallocated or everything is allocated > because everything was already written to. 69f47505ee added a heuristic > to qcow2 to get around this, but I think that’s too much for vhdx. I > just left it unfixed, because I don’t care that much, honestly (and I > don’t think anyone else does). > > > Max Reitz (3): > vdi: Make block_status recurse for fixed images > vmdk: Make block_status recurse for flat extents > vpc: Do not return RAW from block_status > > block/vdi.c | 3 ++- > block/vmdk.c | 3 +++ > block/vpc.c | 2 +- > 3 files changed, 6 insertions(+), 2 deletions(-)
Thanks for the reviews, applied to my block-next branch: https://git.xanclic.moe/XanClic/qemu/commits/branch/block-next Max
signature.asc
Description: OpenPGP digital signature
