@@ -1993,11 +1993,9 @@ static int map_is_allocated(BlockDriverState *bs, int64_t offset,
int64_t bytes, int64_t *pnum)
{
int64_t num;
- int num_checked;
int ret, firstret;
- num_checked = MIN(bytes, BDRV_REQUEST_MAX_BYTES);
- ret = bdrv_is_allocated(bs, offset, num_checked, &num);
+ ret = bdrv_is_allocated(bs, offset, bytes, &num);
if (ret < 0) {
return ret;
}
@@ -2009,8 +2007,7 @@ static int map_is_allocated(BlockDriverState *bs, int64_t offset,
offset += num;
bytes -= num;
- num_checked = MIN(bytes, BDRV_REQUEST_MAX_BYTES);
- ret = bdrv_is_allocated(bs, offset, num_checked, &num);
+ ret = bdrv_is_allocated(bs, offset, bytes, &num);
if (ret == firstret && num) {
*pnum += num;
} else {
The block layer has supported 64-bit block status from drivers since commit 86a3d5c688 ("block: Add .bdrv_co_block_status() callback", v2.12) and friends, with individual driver callbacks responsible for capping things where necessary. Artificially capping things below 2G in the qemu-io 'map' command, added in commit d6a644bbfe ("block: Make bdrv_is_allocated() byte-based", v2.10) is thus no longer necessary. One way to test this is with qemu-nbd as server on a raw file larger than 4G (the entire file should show as allocated), plus 'qemu-io -f raw -c map nbd://localhost --trace=nbd_\*' as client. Prior to this patch, the NBD_CMD_BLOCK_STATUS requests are fragmented at 0x7ffffe00 distances; with this patch, the fragmenting changes to 0x7fffffff (since the NBD protocol is currently still limited to 32-bit transactions - see block/nbd.c:nbd_client_co_block_status). Then in later patches, once I add an NBD extension for a 64-bit block status, the same map command completes with just one NBD_CMD_BLOCK_STATUS. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20211203231539.3900865-3-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> --- qemu-io-cmds.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)