From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WiTAH-00066L-T6 for qemu-devel@nongnu.org; Thu, 08 May 2014 14:35:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WiTAB-0002HW-Dc for qemu-devel@nongnu.org; Thu, 08 May 2014 14:35:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WiTAB-0002Gx-5L for qemu-devel@nongnu.org; Thu, 08 May 2014 14:35:23 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s48IZMFY000683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 May 2014 14:35:22 -0400 Message-ID: <536BCE66.6090105@redhat.com> Date: Thu, 08 May 2014 20:35:18 +0200 From: Max Reitz MIME-Version: 1.0 References: <1399402854-24559-1-git-send-email-mreitz@redhat.com> <536951A9.1070200@redhat.com> <53695863.9080009@redhat.com> <87ha52jfnp.fsf@blackfin.pond.sub.org> In-Reply-To: <87ha52jfnp.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] block/raw-posix: Try both FIEMAP and SEEK_HOLE List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Eric Blake Cc: Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi On 07.05.2014 07:56, Markus Armbruster wrote: > Eric Blake writes: > >> On 05/06/2014 03:18 PM, Eric Blake wrote: >> >>> ...if you are on a file system where SEEK_HOLE triggers the kernel >>> fallback of "entire file is allocated", but where FIEMAP is wired up for >>> that file system, would it make sense to have try_seek_hole return -1 in >>> situations where lseek(s->fd, 0, SEEK_HOLE) returns the end of the file? >>> Even more, should skip_seek_hole be a tri-state? >> On the other hand, such systems are getting vanishingly rare as people >> upgrade to newer kernels. Do we care about catering to them, or is it >> fair game to just tell people to upgrade if they want performance? > My tolerance for code complications to speed up things under old kernels > isn't zero, but close. Leave these games to downstreams sporting such > kernels. As far as I see it, it isn't an optimization for older but for newer kernels. Including Paolo's comment for v3, we could get away without these tristate shenanigans if we'd keep the old (current) order, that is, first try FIEMAP which will return ENOTSUP if it's not supported, and then fall back to SEEK_HOLE which will always return some result (if available, otherwise we can't even use it, obviously). But as SEEK_HOLE is apparently the more "standard" way to acquire the required information, using it first is an optimization for newer systems (older Linux systems and/or older drivers will only provide FIEMAP). I think there is no big performance penality in trying FIEMAP first, as the first call to raw_co_get_block_status() will detect that it is not available for the given file and therefore will be skipped from then on anyway. Considering this, I guess I'll send a v4 without any tristates and which keeps the old order (FIEMAP first and then SEEK_HOLE). Max