Skip to content
  • Eric Blake's avatar
    8417e137
    qemu-img: Make unallocated part of backing chain obvious in map · 8417e137
    Eric Blake authored
    
    
    The recently-added NBD context qemu:allocation-depth is able to
    distinguish between locally-present data (even when that data is
    sparse) [shown as depth 1 over NBD], and data that could not be found
    anywhere in the backing chain [shown as depth 0]; and the libnbd
    project was recently patched to give the human-readable name "absent"
    to an allocation-depth of 0.  But qemu-img map --output=json predates
    that addition, and has the unfortunate behavior that all portions of
    the backing chain that resolve without finding a hit in any backing
    layer report the same depth as the final backing layer.  This makes it
    harder to reconstruct a qcow2 backing chain using just 'qemu-img map'
    output, especially when using "backing":null to artificially limit a
    backing chain, because it is impossible to distinguish between a
    QCOW2_CLUSTER_UNALLOCATED (which defers to a [missing] backing file)
    and a QCOW2_CLUSTER_ZERO_PLAIN cluster (which would override any
    backing file), since both types of clusters otherwise show as
    "data":false,"zero":true" (but note that we can distinguish a
    QCOW2_CLUSTER_ZERO_ALLOCATED, which would also have an "offset":
    listing).
    
    The task of reconstructing a qcow2 chain was made harder in commit
    0da98568 (nbd: server: Report holes for raw images), because prior
    to that point, it was possible to abuse NBD's block status command to
    see which portions of a qcow2 file resulted in BDRV_BLOCK_ALLOCATED
    (showing up as NBD_STATE_ZERO in isolation) vs. missing from the chain
    (showing up as NBD_STATE_ZERO|NBD_STATE_HOLE); but now qemu reports
    more accurate sparseness information over NBD.
    
    An obvious solution is to make 'qemu-img map --output=json' add an
    additional "present":false designation to any cluster lacking an
    allocation anywhere in the chain, without any change to the "depth"
    parameter to avoid breaking existing clients.  The iotests have
    several examples where this distinction demonstrates the additional
    accuracy.
    
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
    Message-Id: <20210701190655.2131223-3-eblake@redhat.com>
    Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
    [eblake: fix more iotest fallout]
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
    8417e137
    qemu-img: Make unallocated part of backing chain obvious in map
    Eric Blake authored
    
    
    The recently-added NBD context qemu:allocation-depth is able to
    distinguish between locally-present data (even when that data is
    sparse) [shown as depth 1 over NBD], and data that could not be found
    anywhere in the backing chain [shown as depth 0]; and the libnbd
    project was recently patched to give the human-readable name "absent"
    to an allocation-depth of 0.  But qemu-img map --output=json predates
    that addition, and has the unfortunate behavior that all portions of
    the backing chain that resolve without finding a hit in any backing
    layer report the same depth as the final backing layer.  This makes it
    harder to reconstruct a qcow2 backing chain using just 'qemu-img map'
    output, especially when using "backing":null to artificially limit a
    backing chain, because it is impossible to distinguish between a
    QCOW2_CLUSTER_UNALLOCATED (which defers to a [missing] backing file)
    and a QCOW2_CLUSTER_ZERO_PLAIN cluster (which would override any
    backing file), since both types of clusters otherwise show as
    "data":false,"zero":true" (but note that we can distinguish a
    QCOW2_CLUSTER_ZERO_ALLOCATED, which would also have an "offset":
    listing).
    
    The task of reconstructing a qcow2 chain was made harder in commit
    0da98568 (nbd: server: Report holes for raw images), because prior
    to that point, it was possible to abuse NBD's block status command to
    see which portions of a qcow2 file resulted in BDRV_BLOCK_ALLOCATED
    (showing up as NBD_STATE_ZERO in isolation) vs. missing from the chain
    (showing up as NBD_STATE_ZERO|NBD_STATE_HOLE); but now qemu reports
    more accurate sparseness information over NBD.
    
    An obvious solution is to make 'qemu-img map --output=json' add an
    additional "present":false designation to any cluster lacking an
    allocation anywhere in the chain, without any change to the "depth"
    parameter to avoid breaking existing clients.  The iotests have
    several examples where this distinction demonstrates the additional
    accuracy.
    
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
    Message-Id: <20210701190655.2131223-3-eblake@redhat.com>
    Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
    [eblake: fix more iotest fallout]
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
Loading