Il 19/07/2013 12:04, Peter Lieven ha scritto: > On 19.07.2013 11:58, Paolo Bonzini wrote: >> 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. > i was told that has_zero_init sole task is to report the state > of the device right after iscsi_create(). using it for r/w in qemu > might be a misuse.
Yes, and here I'm using it exactly for that task. I'm saying "treat a zero block as allocated if it wasn't zero right after _create()". >> 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. > > you mean for every call to the deprecated bdrv_is_allocate()? Of course I'm not advocating returning 1 for every call. But if the semantic isn't clear, I prefer to err on the safe side. Paolo
