Re: [Qemu-devel] [PATCH v2 17/17] block: look for zero blocks in bs->file

[Peter Lieven]

Am 19.07.2013 19:07, schrieb Paolo Bonzini:
> Il 19/07/2013 09:33, Stefan Hajnoczi ha scritto:
>> On Tue, Jul 16, 2013 at 06:29:28PM +0200, Paolo Bonzini wrote:
>>> diff --git a/block.c b/block.c
>>> index 557ce29..2d7d71f 100644
>>> --- a/block.c
>>> +++ b/block.c
>>> @@ -2977,7 +2977,7 @@ static int64_t coroutine_fn 
>>> bdrv_co_get_block_status(BlockDriverState *bs,
>>>                                                       int nb_sectors, int 
>>> *pnum)
>>>  {
>>>      int64_t n;
>>> -    int64_t ret;
>>> +    int64_t ret, ret2;
>>>  
>>>      if (sector_num >= bs->total_sectors) {
>>>          *pnum = 0;
>>> @@ -3003,6 +3003,14 @@ static int64_t coroutine_fn 
>>> bdrv_co_get_block_status(BlockDriverState *bs,
>>>          ret |= BDRV_BLOCK_ZERO;
>>>      }
>>>  
>>> +    if (bs->file &&
>>> +        (ret & BDRV_BLOCK_DATA) && !(ret & BDRV_BLOCK_ZERO) &&
>>> +        (ret & BDRV_BLOCK_OFFSET_VALID)) {
>>> +        ret2 = bdrv_co_get_block_status(bs->file, ret >> BDRV_SECTOR_BITS,
>>> +                                        *pnum, pnum);
>>> +        ret |= (ret2 & BDRV_BLOCK_ZERO);
>>> +    }
>> This patch breaks qemu-iotests 030 (image streaming).
>>
>> The problem is that bdrv_co_get_block_status() uses bs->total_sectors
>> directly instead of calling bdv_get_geometry()/bdrv_getlength().
>>
>> With qcow2 the bs->file can grow on disk.  We don't update
>> bs->total_sectors.
>>
>> Then this patch calls bdrv_co_get_block_status(bs->file) where we fail
>> with *pnum = 0, ret = 0 because bs->total_sectors suggests it is beyond
>> the end of the file.
>>
>> The result is that 030 goes into an infinite loop.
>>
>> As a quick test I switched the direct bs->total_sectors accesses to
>> bdrv_get_geometry() and it stopped hanging.  Perhaps the
>> bs->total_sectors caching needs to be improved though.
> Yes, fixing the caching also resolves the failure.  I'll send a v3 next
> Monday or perhaps Sunday.
Do you have the v3 ready?