From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etc0V-0004my-Vl for qemu-devel@nongnu.org; Wed, 07 Mar 2018 11:33:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1etc0T-0000BY-2U for qemu-devel@nongnu.org; Wed, 07 Mar 2018 11:33:35 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:38852) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1etc0S-0000B2-T4 for qemu-devel@nongnu.org; Wed, 07 Mar 2018 11:33:33 -0500 Received: by mail-wm0-f68.google.com with SMTP id z9so5852609wmb.3 for ; Wed, 07 Mar 2018 08:33:32 -0800 (PST) References: <20180226170313.8178-1-mreitz@redhat.com> <20180227161743.GC32480@stefanha-x1.localdomain> <2fddac03-cde4-8d83-7651-a3928398e909@redhat.com> <20180306134757.GH31045@stefanha-x1.localdomain> <20180306173718.GK7139@localhost.localdomain> From: Paolo Bonzini Message-ID: Date: Wed, 7 Mar 2018 17:33:29 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , Kevin Wolf , Stefan Hajnoczi Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org On 07/03/2018 16:57, Max Reitz wrote: >>>> (2) For sparse raw images, this is absolutely devastating. Reading them >>>> now takes more than (ext4) or nearly (xfs) twice as much time as reading >>>> a fully allocated image. So much for "if a filesystem driver has any >>>> sense". >> Are you sure that only the filesystem is the problem? Checking for every >> single byte of an image whether it is zero has to cost some performance. > Well, yes, but "read data location from FS metadata" + "realize it's a > hole" + memset() + "repe scasb" shouldn't take twice as much time as > "read data location from FS metadata" + "read data from SSD". > > I expected the "realize it's a hole" part to fall out for free, so this > would that memset() + repe scasb take much longer than reading data from > the SSD -- and that's just pretty much impossible. > This makes a lot of sense, but just to double-check, what does profiling say? Paolo