On 6/29/20 5:39 AM, Stefan Hajnoczi wrote:
SCSI defines 3 values and QEMU can represent all of them:
0 - mapped or unknown
1 - deallocated
2 - anchored
See the BDRV_BLOCK_* constants in include/block/block.h. The
is_deallocated boolean is not enough to represent this state, but the
bdrv_block_status() return value can be used instead.
I don't know which one in BDRV_BLOCK_* can be used to represent 'anchored'.
It seems that I need to use BDRV_BLOCK_* combination to recognized 'anchored',
I'd like to use these combinations to analyze the bdrv_block_status() return
value:
'deallocated': BDRV_BLOCK_ALLOCATED | BDRV_BLOCK_OFFSET_VALID | BDRV_BLOCK_ZERO
'anchored': BDRV_BLOCK_ALLOCATED | BDRV_BLOCK_OFFSET_VALID | !
BDRV_BLOCK_ZERO | ! BDRV_BLOCK_DATA
Am I right?
My understanding is that the SCSI status are mapped to QEMU block status
as follows:
allocated: BDRV_BLOCK_DATA | !BDRV_BLOCK_ZERO | BDRV_BLOCK_OFFSET_VALID
I haven't read the scsi code, but as written, I would assume that any
portion of the block status with this result has the following properties:
- reading sees guest-visible data; we cannot guarantee whether it is all
zero, and the data reserves actual space
anchored: BDRV_BLOCK_DATA | BDRV_BLOCK_ZERO | BDRV_BLOCK_OFFSET_VALID
- reading sees all zeros, but the disk has reserved actual space such
that future writes will not run out of space
deallocated: !BDRV_BLOCK_DATA
- reading does not see data; future writes will have to reserve space.
I would expect this option might also have '| BDRV_BLOCK_ZERO' depending
on whether this particular scsi device guarantees that reads of an
unallocated portion see all zeros instead of unspecified garbage.
I have CCed Eric Blake, who is familiar with block status.
Adding Vladimir in CC as well, as he has pending patches that try to
clear up the use of BDRV_BLOCK_* constants with regards to two different
queries:
- allocation implies that data comes from this layer of a backing chain,
rather than deferring to a backing image
- allocation implies that storage is reserved (that is, not sparse)
It sounds like we are trying to represent the second question for scsi
(namely, the same question that gets answered by lseek(SEEK_HOLE) for
POSIX files), and not the first (namely, the question answered for qcow2
images).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
