From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42974) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ctrPI-0006TM-J1 for qemu-devel@nongnu.org; Fri, 31 Mar 2017 03:55:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ctrPE-0003Up-Nl for qemu-devel@nongnu.org; Fri, 31 Mar 2017 03:55:40 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:44270 helo=mx01.kamp.de) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ctrPE-0003RG-Dr for qemu-devel@nongnu.org; Fri, 31 Mar 2017 03:55:36 -0400 References: <82d604c8-068a-aff4-6037-e3cd247b3588@redhat.com> <819af057-3777-dffc-4670-895b8265fd01@kamp.de> <32e1e781-f0b0-ac67-a5ce-74ccc64071a0@kamp.de> <20170320024649.GA18938@lemon.lan> <37879546-cf6e-01fa-adc6-c777e14eab0e@redhat.com> <20170320114926.GB17020@lemon.lan> <4aa3e0fc-1176-af7d-bef9-2b881a984605@kamp.de> <293a74e1-f355-6969-9b76-9913e7f56930@kamp.de> <5cb7f3f5-cd3f-b54c-3109-140dee3b2cad@redhat.com> From: Peter Lieven Message-ID: <3c972a26-18a1-2636-ed80-6b73b972401d@kamp.de> Date: Fri, 31 Mar 2017 09:55:31 +0200 MIME-Version: 1.0 In-Reply-To: <5cb7f3f5-cd3f-b54c-3109-140dee3b2cad@redhat.com> Content-Type: text/plain; charset=windows-1252 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: Paolo Bonzini , Fam Zheng Cc: "qemu-devel@nongnu.org" , qemu block Am 27.03.2017 um 17:06 schrieb Paolo Bonzini: > > On 27/03/2017 15:21, Peter Lieven wrote: >>>> I stumbled across the issue with lseek on a tmpfs because in the >>>> build process for our templates >>>> I temporarily have vmdks on a tmpfs and it takes ages before qemu-img >>>> convert starts to run (it iterates >>>> over every 64kb cluster with that callout to find_allocation and for >>>> some reason lseek is very slow on tmpfs). >>> Ok, thanks. Perhaps it's worth benchmarking tmpfs specifically. Apart >>> from the system call overhead (which does not really matter if you're >>> going to do a read), lseek on other filesystems should not be any slower >>> than read. >> Okay, but the even the read is not really necessary if the metadata is >> correct? > Yeah, what I mean is: > > - if you're going to do a read of non-zero blocks, the lseek you do > before reading those blocks should not matter. > > - if you're going to skip the read of non-zero blocks, the lseek you do > is always going to be faster than reading them and then checking with > buffer_is_nonzero. > >> Would it be an idea to introduce an inverse flag live BDRV_BLOCK_NOT_ZERO >> for cases where we know that there is really DATA and thus can avoid the >> second callout? > How would you know that a block is nonzero? I would trust the metadata. At least for VMDK and QCOW2v3. Bad idea? Peter