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
