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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
