|
From: | Peter Lieven |
Subject: | Re: [Qemu-devel] [PATCH v2 10/17] block: define get_block_status return value |
Date: | Fri, 19 Jul 2013 15:06:58 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 |
On 19.07.2013 14:13, Paolo Bonzini wrote:
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()".
If it is zero and allocated the API should return only BDRV_BLOCK_DATA and if it is zero and unallocated only BDRV_BLOCK_ZERO or not? What I mean is the new API shouldn't change the behaviour of the old bdrv_is_allocated(). It would have returned (ret & BDRV_BLOCK_DATA) regardless if BDRV_BLOCK_ZERO or not. Peter
[Prev in Thread] | Current Thread | [Next in Thread] |