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: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCHv3 1.8 1/9] qemu-img: add support for skipping zeroes in input during convert
Date: Thu, 5 Dec 2013 11:30:08 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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!



reply via email to

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