Re: [Qemu-devel] [PATCH v4 23/23] qemu-io: Relax 'alloc' now that block-status doesn't assert

[John Snow <jsnow@redhat.com>]

On 10/02/2017 07:56 PM, Eric Blake wrote:
> On 10/02/2017 04:27 PM, John Snow wrote:
>>
>>
>> On 09/13/2017 12:03 PM, Eric Blake wrote:
>>> Previously, the alloc command required that input parameters be
>>> sector-aligned and clamped to 32 bits, because the underlying
>>> bdrv_is_allocated used a 32-bit parameter and asserted aligned
>>> inputs.  But now that we have fixed block status to report a
>>> 64-bit bytes value, and to properly round requests on behalf of
>>> guests, we can pass any values, and can use qemu-io to add
>>> coverage that our rounding is correct regardless of the guest
>>> alignment constraints.
>>>
>>> Update iotest 177 to intentionally probe block status at
>>> unaligned boundaries as well as with a bytes value that does not
>>> map to 32-bit sectors, which also required tweaking the image
>>> prep to leave an unallocated portion to the image under test.
>>>
>>> Signed-off-by: Eric Blake <eblake@redhat.com>
>>>
> 
>>>  echo
>>> +echo "== block status smaller than alignment =="
>>> +limits=align=4k
>>> +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \
>>> +	 -c "alloc 1 1" -c "alloc 0x6dffff0 1000" -c "alloc 127m 5P" \
>>> +	 -c map | _filter_qemu_io
>>> +
> 
>>
>> aaand I'll hold off on this one until the respin so I don't have to
>> review the test twice.
> 
> Fair enough; thanks for the reviews.
> 
> By the way, it's operations like the above additions where you can step
> through bdrv_co_block_status in gdb to see all the rounding/alignment
> steps in action, so I do feel pretty confident that my changes in 21/23
> were fairly well covered.
> 

I do actually trust you, but I wasn't able to *quickly* convince myself,
so I held up on the r-b. I didn't spot any problems either, to be fair...!

>>
>> I'll say I'm done for v4 for now :)
> 
> I'll try to get v5 posted in the next day or two.
> 

No rush on my end ...

--js