From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1copbQ-00086e-TA for qemu-devel@nongnu.org; Fri, 17 Mar 2017 06:59:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1copbQ-0004Oj-4b for qemu-devel@nongnu.org; Fri, 17 Mar 2017 06:59:24 -0400 References: From: Paolo Bonzini Message-ID: <82d604c8-068a-aff4-6037-e3cd247b3588@redhat.com> Date: Fri, 17 Mar 2017 11:59:16 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] callout to *file in bdrv_co_get_block_status List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven , qemu block , "qemu-devel@nongnu.org" Cc: Fam Zheng On 17/03/2017 11:45, Peter Lieven wrote: > 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? It provides additional information, for example it works better with prealloc=metadata. Paolo