From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Sandeen Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2 Date: Fri, 27 Jun 2008 23:21:36 -0500 Message-ID: <4865BC50.2030804@redhat.com> References: <20080625221835.GQ28100@wotan.suse.de> <4863A1C5.7020403@redhat.com> <20080627014119.GW29319@disturbed> <20080627094156.GA30200@shareable.org> <20080627224843.GZ6239@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jamie Lokier , Mark Fasheh , linux-fsdevel@vger.kernel.org, Andreas Dilger , Kalpak Shah , Josef Bacik To: Andreas Dilger Return-path: Received: from mx1.redhat.com ([66.187.233.31]:60055 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751264AbYF1EVq (ORCPT ); Sat, 28 Jun 2008 00:21:46 -0400 In-Reply-To: <20080627224843.GZ6239@webber.adilger.int> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Andreas Dilger wrote: >> - The filesystem's internal representation may have _many_ more >> extents than the contiguous layout. E.g. a 4GiB file might have >> 65536 x 64kiB extents on some filesystem, or 1 extent when >> merged. Is it ever useful to return the much larger list? > > It seems unlikely to consider this an "extent based" filesystem, and > I'd treat it as a block-based filesystem internally and merge it... > Yes, for ext4 it must split the extents at 128MB boundaries (1 group), > but because of the on-disk metadata it isn't yet possible to allocate > larger extents anyways. aside: even w/ metadata out of the way the ext4 extent format is still capped at 128M per extent right, even if they're contiguous. Which led me to the little though experiment about hm, is this 1G file 1 extent or 8 and what should fiemap return... -Eric