From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris Wedgwood <cw@f00f.org>
Subject: Re: SEEK_HOLE and SEEK_DATA
Date: Fri, 3 Feb 2006 11:37:56 -0800
Message-ID: <20060203193756.GA5254@taniwha.stupidest.org>
References: <20060202090349.31898.qmail@science.horizon.com> <20060203180821.GA4739@taniwha.stupidest.org> <Pine.LNX.4.61.0602032008580.16335@dhcppc0>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux@horizon.com, linux-fsdevel@vger.kernel.org
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from smtp102.sbc.mail.mud.yahoo.com ([68.142.198.201]:37277 "HELO
	smtp102.sbc.mail.mud.yahoo.com") by vger.kernel.org with SMTP
	id S1422676AbWBCTiA (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
	Fri, 3 Feb 2006 14:38:00 -0500
To: Szakacsits Szabolcs <szaka@sienet.hu>
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0602032008580.16335@dhcppc0>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Fri, Feb 03, 2006 at 08:23:51PM +0200, Szakacsits Szabolcs wrote:

> 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).

If there was something consistent across all filesystems albeit it
different to SEEK_HOLE & SEEK_DATA those could be implemented in
glibc.

Given we've gotten along fine without them for some time I don't see
that a little bit of thought and taking some time to chew over this
will do any harm.