qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCHv3 1.8 1/9] qemu-img: add support for skipping ze


From: Peter Lieven
Subject: Re: [Qemu-devel] [PATCHv3 1.8 1/9] qemu-img: add support for skipping zeroes in input during convert
Date: Wed, 04 Dec 2013 17:51:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1

Am 04.12.2013 17:46, schrieb Stefan Hajnoczi:
> On Wed, Nov 27, 2013 at 11:07:01AM +0100, Peter Lieven wrote:
>> +                /* If the output image is being created as a copy on write
>> +                 * image, assume that sectors which are unallocated in the
>> +                 * input image are present in both the output's and input's
>> +                 * base images (no need to copy them). */
>> +                if (out_baseimg) {
>> +                    if (!(ret & BDRV_BLOCK_DATA)) {
>> +                        sector_num += n1;
>> +                        continue;
>> +                    }
>> +                    /* The next 'n1' sectors are allocated in the input 
>> image.
>> +                     * Copy only those as they may be followed by 
>> unallocated
>> +                     * sectors. */
>> +                    nb_sectors = n1;
>> +                }
>> +                /* avoid redundant callouts to get_block_status */
>> +                sector_num_next_status = sector_num + n1;
> Can you explain when we need sector_num_next_status?  It's not clear to
> me from this patch when we will loop around already knowing that blocks
> are allocated.
We call get_block_status with MIN(INT_MAX, nb_sectors). So we might
receive an allocation status for a huge area. Later we trim the request
size to MIN(iobuf_size, nb_sectors) and eventually align the request.

For example take a fully allocated image on an iSCSI san. I can easily get
that information with the first get_block_status call, but I repeat these
calls over and over and in case of the iSCSI SAN these calls are quite
expensive.

Peter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]