Re: [PATCH] qemu-img map: Don't limit block status request size

From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [PATCH] qemu-img map: Don't limit block status request size
Date: Tue, 7 Jul 2020 17:21:47 +0200	[thread overview]
Message-ID: <20200707152147.GC7002@linux.fritz.box> (raw)
In-Reply-To: <9f74d8dc-9c4e-d519-9dd7-0895ece3de17@redhat.com>

Am 07.07.2020 um 16:54 hat Eric Blake geschrieben:
> On 7/7/20 9:46 AM, Kevin Wolf wrote:
> > Limiting each loop iteration of qemu-img map to 1 GB was arbitrary from
> > the beginning, though it only cut the maximum in half then because the
> > interface a signed 32 bit byte count. These days, bdrv_block_status()
> > supports a 64 bit byte count, so the arbitrary limit is even worse.
> > 
> > On file-posix, bdrv_block_status() eventually maps to SEEK_HOLE and
> > SEEK_DATA, which don't support a limit, but always do all of the work
> > necessary to find the start of the next hole/data. Much of this work may
> > be repeated if we don't use this information fully, but query with an
> > only slightly larger offset in the next loop iteration. Therefore, if
> > bdrv_block_status() is called in a loop, it should always pass the
> > full number of bytes that the whole loop is interested in.
> > 
> > This removes the arbitrary limit and speeds up 'qemu-img map'
> > significantly on heavily fragmented images.
> > 
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> >   qemu-img.c | 5 +----
> >   1 file changed, 1 insertion(+), 4 deletions(-)
> 
> Do you want this in 5.1?  It seems like a nice optimization.

I guess now that I have your R-b, I can sneak both patches in for soft
freeze. :-)

Kevin