On Wed, Dec 04, 2013 at 05:51:20PM +0100, Peter Lieven wrote:
> 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.
Makes sense, thanks!
