From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?B?SsO2cm4=?= Engel Subject: Re: [RFC][PATCH] Implement SEEK_HOLE/SEEK_DATA Date: Thu, 29 Nov 2007 00:48:43 +0100 Message-ID: <20071128234842.GA8664@lazybastard.org> References: <20071128200206.GB3977@dhcp243-37.rdu.redhat.com> <1196290614.18231.17.camel@entropy> <20071128233959.GF4913@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Nicholas Miell , Josef Bacik , linux-fsdevel@vger.kernel.org, Andreas Dilger To: Andreas Dilger Return-path: Received: from lazybastard.de ([212.112.238.170]:33628 "EHLO longford.lazybastard.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751381AbXK1Xx7 (ORCPT ); Wed, 28 Nov 2007 18:53:59 -0500 Content-Disposition: inline In-Reply-To: <20071128233959.GF4913@webber.adilger.int> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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_EXTENT= S, > > EXTENT_TYPE_COMPRESSED, EXTENT_TYPE_UNCOMPRESSED etc. >=20 > This is what FIEMAP is supposed to do. We wrote a spec and implement= ed > a prototype for ext4, but haven't had time to make it generic to move > the large part of the code into the VFS. If someone wanted to take t= hat > 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. 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 tightl= y as possible (byte alignment). 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 exposed, SEEK_HOLE/SEEK_DATA is significantly more elegant for logfs. If not, =46IEMAP could be useful. J=C3=B6rn --=20 Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. -- Rob Pike - 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