Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2

[Dave Chinner <david@fromorbit.com>]

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