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 <kw...@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
