From mboxrd@z Thu Jan 1 00:00:00 1970 From: Szakacsits Szabolcs Subject: Re: SEEK_HOLE and SEEK_DATA Date: Fri, 3 Feb 2006 20:23:51 +0200 (MET DST) Message-ID: References: <20060202090349.31898.qmail@science.horizon.com> <20060203180821.GA4739@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: linux@horizon.com, linux-fsdevel@vger.kernel.org Return-path: Received: from fep02-0.kolumbus.fi ([193.229.0.44]:16504 "EHLO fep02-app.kolumbus.fi") by vger.kernel.org with ESMTP id S1751350AbWBCS01 (ORCPT ); Fri, 3 Feb 2006 13:26:27 -0500 To: Chris Wedgwood In-Reply-To: <20060203180821.GA4739@taniwha.stupidest.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 3 Feb 2006, Chris Wedgwood wrote: > On Thu, Feb 02, 2006 at 04:03:49AM -0500, linux@horizon.com wrote: > > > Solaris 10 has added a moderately useful new feature... lseek now > > supports whence = 3 (SEEK_DATA) and 4 (SEEK_HOLE). What these do is > > advance the file pointer to the start of the next run of the > > appropriate kind past the given (absolute) offset. > > Some filesystems in linux (XFS for one, probably others?) already have > a mechanism (albeit more complex the way it's exposed) to find holes & > data. NTFS, though not the Linux driver. Both XFS_IOC_GETBMAPX and FSCTL_QUERY_ALLOCATED_RANGE are much more efficient than SEEK_HOLE/SEEK_DATA (and let's forget about FIBMAP). Szaka