From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csWES-00072S-JJ for qemu-devel@nongnu.org; Mon, 27 Mar 2017 11:06:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1csWER-0007t4-Mb for qemu-devel@nongnu.org; Mon, 27 Mar 2017 11:06:56 -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> From: Paolo Bonzini Message-ID: <5cb7f3f5-cd3f-b54c-3109-140dee3b2cad@redhat.com> Date: Mon, 27 Mar 2017 17:06:47 +0200 MIME-Version: 1.0 In-Reply-To: <293a74e1-f355-6969-9b76-9913e7f56930@kamp.de> 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: Peter Lieven , Fam Zheng Cc: "qemu-devel@nongnu.org" , qemu block 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? Paolo