From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2 Date: Fri, 27 Jun 2008 20:01:02 +1000 Message-ID: <20080627100102.GB29319@disturbed> References: <20080625221835.GQ28100@wotan.suse.de> <4863A1C5.7020403@redhat.com> <20080627014119.GW29319@disturbed> <20080627094156.GA30200@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Eric Sandeen , Mark Fasheh , linux-fsdevel@vger.kernel.org, Andreas Dilger , Kalpak Shah , Josef Bacik To: Jamie Lokier Return-path: Received: from ipmail04.adl2.internode.on.net ([203.16.214.57]:32457 "EHLO ipmail04.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752567AbYF0KBH (ORCPT ); Fri, 27 Jun 2008 06:01:07 -0400 Content-Disposition: inline In-Reply-To: <20080627094156.GA30200@shareable.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Jun 27, 2008 at 10:41:56AM +0100, Jamie Lokier wrote: > Dave Chinner wrote: > > > Right now the interface seems to be about returning details of the > > > filesystem's accounting of the on-disk layout, as opposed to just a > > > simple mapping. As 2 examples: > > > > IMO we shouldn't complicate the kernel implementation - if the user > > wants to see merged extents, merge them in userspace. If the user > > want's trimmed extents, do it in userspace. If the use wants > > every raw extent, then nothing else needs to be done... > > Agree, in general, but for merging a couple of things spring to mind: > > - The block based implementation must merge the filesystem's > internal representation, i.e. each block. Not doing this would > return a prohibitively large list of block-size extents. Given there's a massage layer between the bmap and extent based fs's already, it could be handled there. > - 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? 64k max extent size? I'd consider that a block based filesystem, not an extent based filesytem.... Cheers, Dave. -- Dave Chinner david@fromorbit.com