From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2 Date: Fri, 27 Jun 2008 16:48:43 -0600 Message-ID: <20080627224843.GZ6239@webber.adilger.int> 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 Content-Transfer-Encoding: 7BIT Cc: Eric Sandeen , Mark Fasheh , linux-fsdevel@vger.kernel.org, Andreas Dilger , Kalpak Shah , Josef Bacik To: Jamie Lokier Return-path: Received: from sca-es-mail-2.Sun.COM ([192.18.43.133]:42050 "EHLO sca-es-mail-2.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755743AbYF0Wsr (ORCPT ); Fri, 27 Jun 2008 18:48:47 -0400 Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5RMmjuv012442 for ; Fri, 27 Jun 2008 15:48:46 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K35001018LKIZ00@fe-sfbay-10.sun.com> (original mail from adilger@sun.com) for linux-fsdevel@vger.kernel.org; Fri, 27 Jun 2008 15:48:45 -0700 (PDT) In-reply-to: <20080627094156.GA30200@shareable.org> Content-disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Jun 27, 2008 10:41 +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. This is already done in the generic_fiemap() implementation for block-based filesystems (ext2, ext3, ext4 with block-mapped files). In that case it sets the FIEMAP_EXTENT_MERGED flag in the returned extent. > - 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. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.