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@xxxxxxxxxxxxx -- 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
