From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2 Date: Fri, 27 Jun 2008 10:41:56 +0100 Message-ID: <20080627094156.GA30200@shareable.org> References: <20080625221835.GQ28100@wotan.suse.de> <4863A1C5.7020403@redhat.com> <20080627014119.GW29319@disturbed> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Eric Sandeen , Mark Fasheh , linux-fsdevel@vger.kernel.org, Andreas Dilger , Kalpak Shah , Josef Bacik Received: from mail2.shareable.org ([80.68.89.115]:40732 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751476AbYF0JmF (ORCPT ); Fri, 27 Jun 2008 05:42:05 -0400 Content-Disposition: inline In-Reply-To: <20080627014119.GW29319@disturbed> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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. - 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? -- Jamie