From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: [RFC][PATCH] Implement SEEK_HOLE/SEEK_DATA Date: Wed, 28 Nov 2007 20:27:11 -0700 Message-ID: <20071129032711.GI4913@webber.adilger.int> 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=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Nicholas Miell , Josef Bacik , linux-fsdevel@vger.kernel.org, Andreas Dilger To: =?iso-8859-1?Q?J=F6rn?= Engel Return-path: Received: from mail.clusterfs.com ([74.0.229.162]:51150 "EHLO mail.clusterfs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752722AbXK2D1R (ORCPT ); Wed, 28 Nov 2007 22:27:17 -0500 Content-Disposition: inline In-Reply-To: <20071128234842.GA8664@lazybastard.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Nov 29, 2007 00:48 +0100, J=F6rn Engel wrote: > 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). The FIEMAP interface in some ways well suited to your needs, because it uses byte offsets instead of FIBMAP, which uses block offsets. I now s= ee that one hole in the specification is that your physical extent is not = the same length as the logical extent that the data represents. I'm not sure that is in itself a reason not to use FIEMAP. There is al= ready a provision for logical extents that do not map directly to the physica= l layout (i.e. FIEMAP_EXTENT_NO_DIRECT flag on the extent). In the case = of logfs, the extent fe_length would represent the logical length of the d= ata that the extent covers, fe_offset is the start of the physical extent, = and =46IEMAP_EXTENT_NO_DIRECT indicates that this extent cannot be directly= mapped. This is useful for applications like LILO that would otherwise assume t= he physical offset can be used to access the data from the block device. It would still provide very useful information about the layout of file= s on disk for filefrag, and if tar or cp used FIEMAP they could know to read= the data from the start up to the end of an extent to avoid waiting for a s= eek in the middle of the IO, and of course skipping holes during copy. A v= ery smart tar might even FIEMAP a whole bunch of files and then read the ex= tents in physical block offset order to reduce seeking. I don't think most applications will care about the actual physical loc= ation of an extent, so much as the relative locations of extents within a fil= e and between files. > 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. SEEK_HOLE/SEEK_DATA only provides a fraction of the useful information that FIEMAP does. It won't give users or developers any information ab= out the on disk layout (which is quite important for knowing if allocation algorithms are good). Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. - 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