Re: [Qemu-devel] [PATCH] block: don't probe zeroes in bs->file by default on block_status

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

On 1/24/19 9:39 AM, Kevin Wolf wrote:

>>>
>>> Hmm, and one more idea from Den:
>>>
>>> We can detect preallocated image, comparing allocated size of real file with
>>> number of non-zero qcow2 refcounts. So, real allocation is much less than
>>> allocation in qcow2 point of view, we'll enable lseeks, otherwise - not.
>>>
>>
>> Kevin, what do you think?
> 
> I'm unsure. I think it requires scanning all refcount blocks in
> qcow2_open(), right? This could be slow on huge images. On the other
> hand, the first cluster allocation will probably do this anyway, so it
> might be reasonable enough.
> 

We could add a qcow2 header to cache the last known values, to make
things faster on open (will only benefit users that know to set/read the
cache; should probably be an autoclear-type feature to detect when an
older user modified the image but not the cache).

We can on first allocation for images being modified - but the use case
in question is 'qemu-img convert' which only reads the image, not writes
it, so yes, it adds a startup delay.  But if the delay is no worse than
the current code, or if it can end early, it may help.  We're using it
as some sort of heuristic; we need to compare the size of the underlying
file to the count of known-allocated clusters in the qcow2 layer (where
internal snapshots may throw things off, and where having a backing file
or not changes whether a sparse file is worth further checking for extra
precision for encountering holes on allocated clusters).

> How would you communicate this? Another block_status return flag that
> says "don't bother to ask the protocol layer" and which we would only
> set in qcow2 if the probing came to the conclusion that it's not
> preallocated?

That could work.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]