From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicholas Miell Subject: Re: [RFC][PATCH] Implement SEEK_HOLE/SEEK_DATA Date: Wed, 28 Nov 2007 16:06:25 -0800 Message-ID: <1196294785.18231.31.camel@entropy> References: <20071128200206.GB3977@dhcp243-37.rdu.redhat.com> <1196290614.18231.17.camel@entropy> <20071128233959.GF4913@webber.adilger.int> <20071128234842.GA8664@lazybastard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Andreas Dilger , Josef Bacik , linux-fsdevel@vger.kernel.org, Andreas Dilger To: =?ISO-8859-1?Q?J=F6rn?= Engel Return-path: Received: from qmta03.westchester.pa.mail.comcast.net ([76.96.62.32]:35192 "EHLO QMTA03.westchester.pa.mail.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758280AbXK2AG3 (ORCPT ); Wed, 28 Nov 2007 19:06:29 -0500 In-Reply-To: <20071128234842.GA8664@lazybastard.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2007-11-29 at 00:48 +0100, J=C3=B6rn Engel wrote: > On Wed, 28 November 2007 16:39:59 -0700, Andreas Dilger wrote: > > On Nov 28, 2007 14:56 -0800, Nicholas Miell wrote: > > >=20 > > > type: one of EXTENT_TYPE_HOLE, EXTENT_TYPE_DATA, EXTENT_TYPE_EXTE= NTS, > > > EXTENT_TYPE_COMPRESSED, EXTENT_TYPE_UNCOMPRESSED etc. > >=20 > > This is what FIEMAP is supposed to do. We wrote a spec and impleme= nted > > a prototype for ext4, but haven't had time to make it generic to mo= ve > > the large part of the code into the VFS. If someone wanted to take= that > > up, it would be much appreciated. > >=20 > > See "[RFC] add FIEMAP ioctl to efficiently map file allocation" in > > linux-fsdevel for details on this interface. >=20 > I didn't follow the discussion much, since it didn't appear to suit > logfs too well. In a nutshell, logfs is purely block-based, prepends > every block with a header, may compress blocks and packs them as tigh= tly > as possible (byte alignment). >=20 > Maybe the "MAP" part fooled me to believe FIEMAP would also expose > physical location of extends on the medium. But reading the proposal > again, I am unsure about that part. If physical locations are expose= d, > SEEK_HOLE/SEEK_DATA is significantly more elegant for logfs. If not, > FIEMAP could be useful. >=20 > J=C3=B6rn >=20 I'd have to reread the original proposal, but I remember FIEMAP as bein= g a generalized way of getting information about a files extents. I think the original proposal only dealt with mapping file offsets to physical extents, but IIRC the interface was flexible enough to implement a "where are the holes" request. Regardless, SEEK_HOLE/SEEK_DATA being a better suited interface for the needs of logfs doesn't make it the best interface for that need. --=20 Nicholas Miell - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html