Hi,
I tried to debug why qemu-img convert with a VMDK source laying on a tmpfs is
horrible slow.
For some reason a lseek on a tmpfs is slow. Strictly speaking the lseek in
find_allocation in file-posix.c
is slow.
When qemu-img convert iterates over all sectors of a VMDK file to check their
allocation status it ends
up checking allocation status of all allocated sectors due to the following
condition in bdrv_co_get_block_status:
if (*file && *file != bs &&
(ret & BDRV_BLOCK_DATA) && !(ret & BDRV_BLOCK_ZERO) &&
(ret & BDRV_BLOCK_OFFSET_VALID)) {
BlockDriverState *file2;
int file_pnum;
ret2 = bdrv_co_get_block_status(*file, ret >> BDRV_SECTOR_BITS,
*pnum, &file_pnum, &file2);
if (ret2 >= 0) {
/* Ignore errors. This is just providing extra information, it
* is useful but not necessary.
*/
if (!file_pnum) {
/* !file_pnum indicates an offset at or beyond the EOF; it is
* perfectly valid for the format block driver to point to such
* offsets, so catch it and mark everything as zero */
ret |= BDRV_BLOCK_ZERO;
} else {
/* Limit request to the range reported by the protocol driver */
*pnum = file_pnum;
ret |= (ret2 & BDRV_BLOCK_ZERO);
}
}
}
Does anybody remember for what circumstances this case this was added? In case
of an container format
like VMDK or QCOW2 shouldn't we trust the information from the l2 tables in the
VMDK or QCOW2?
Thanks,
Peter