From mboxrd@z Thu Jan 1 00:00:00 1970 From: Szakacsits Szabolcs Subject: Re: SEEK_HOLE and SEEK_DATA Date: Sat, 4 Feb 2006 01:41:52 +0200 (MET DST) Message-ID: References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Chris Wedgwood , linux@horizon.com, linux-fsdevel@vger.kernel.org Return-path: Received: from fep30-0.kolumbus.fi ([193.229.0.32]:51859 "EHLO fep30-app.kolumbus.fi") by vger.kernel.org with ESMTP id S1030248AbWBCXob (ORCPT ); Fri, 3 Feb 2006 18:44:31 -0500 To: Bryan Henderson In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 3 Feb 2006, Bryan Henderson wrote: > It isn't obvious to me that a series of seek/tell are noticeably slower > when copying a file than a single system call that returns a list. It depends on how fast one is able to copy. A special but not so unusual case of this if one doesn't want to copy at all and just interested in querying this information for analyses, future decisions, etc. Then the numbers would be something like this for e.g. a 200 GB sparse file: JFS + FIBMAP 137.80 sec 97% CPU XFS + FIBMAP 117.81 sec 97% CPU ext3 + FIBMAP 88.40 sec 96% CPU XFS + XFS_IOC_GETBMAPX 0.05 sec 95% CPU SEEK_HOLE/SEEK_DATA is somewhere between XFS_IOC_GETBMAPX and FIBMAP, in the worst case half-way. > I usually prefer a special version of read() that shows you holes > explicitly to either of the other approaches, but SEEK_HOLE/SEEK_DATA has > the definite advantage of being a smaller perturbance of the API and > easier to understand. Absolutely. For the price being less useful and efficient. Szaka