qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-block] callout to *file in bdrv_co_get_block_status


From: Peter Lieven
Subject: [Qemu-block] callout to *file in bdrv_co_get_block_status
Date: Fri, 17 Mar 2017 11:45:41 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

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




reply via email to

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