Il 19/07/2013 08:48, Peter Lieven ha scritto: >> >> - return bdrv_get_block_status(bs, sector_num, nb_sectors, pnum); >> + int64_t ret = bdrv_get_block_status(bs, sector_num, nb_sectors, >> pnum); >> + return >> + (ret & BDRV_BLOCK_DATA) || >> + ((ret & BDRV_BLOCK_ZERO) && !bdrv_has_zero_init(bs)); > > i do also not understand the "((ret & BDRV_BLOCK_ZERO) && > !bdrv_has_zero_init(bs))"; > if a block is unallocated and reads as zero, but the device lacks zero > init, it is declared as allocated with this, isn't it?
Thinking more about it, I would say it is a bugfix. If a block is unallocated and reads as zero, but the device lacks zero init, the block contents have changed since the guest was created. Thus the guest might well be relying on the zero content of the block, and it should be treated as allocated. In any case, better safe than sorry---if in doubt, the conservative answer is always to return 1, and callers who want more precise information can use bdrv_get_block_status. Paolo > for iscsi and host_device with lbprz==1 or discardzeroes respectively all > blocks would return as allocated. is this wanted?
