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. -- 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
