Re: [Qemu-devel] [PATCH v2 2/2] block: avoid recursive block_status call if possible

[Kevin Wolf <kwolf@redhat.com>]

Am 08.04.2019 um 18:26 hat Vladimir Sementsov-Ogievskiy geschrieben:
> drv_co_block_status digs bs->file for additional, more accurate search
> for hole inside region, reported as DATA by bs since 5daa74a6ebc.
> 
> This accuracy is not free: assume we have qcow2 disk. Actually, qcow2
> knows, where are holes and where is data. But every block_status
> request calls lseek additionally. Assume a big disk, full of
> data, in any iterative copying block job (or img convert) we'll call
> lseek(HOLE) on every iteration, and each of these lseeks will have to
> iterate through all metadata up to the end of file. It's obviously
> ineffective behavior. And for many scenarios we don't need this lseek
> at all.
> 
> However, lseek is needed when we have metadata-preallocated image.
> 
> So, let's detect metadata-preallocation case and don't dig qcow2's
> protocol file in other cases.
> 
> The idea is to compare allocation size in POV of filesystem with
> allocations size in POV of Qcow2 (by refcounts). If allocation in fs is
> significantly lower, consider it as metadata-preallocation case.
> 
> 102 iotest changed, as our detector can't detect shrinked file as
> metadata-preallocation, which don't seem to be wrong, as with metadata
> preallocation we always have valid file length.
> 
> Other two iotests tiny changed QMP output sequence, which should be
> exactly because skipped lseek at mirror beginning.

No, these hunks don't show an improvement. An earlier {'return':{}}
means that the block job coroutine has yielded earlier, so it's doing a
blocking operation where it didn't do one before the patch.

What happens is that qcow2_detect_metadata_preallocation() causes
additional I/O by reading in the refcount block.

I'll modify the commit message accordingly while applying.

Kevin