On Wed, May 28, 2008 at 01:42:15PM -0600, Andreas Dilger wrote: > > > What about the idea to have fiemap_fill_next_extent() do "extent" merging > > > for filesystems that use the generic helper but do not return multiple > > > blocks via get_blocks()? I don't think that is too hard to implement, > > > and makes the output more useful, otherwise we get an extent per block. > > > The above is what I _think_ will work, haven't actually tried it out. > > > > I don't think we want to automatically merge extents within this helper > > function. Otherwise we would diverge from the actual disk layout for extent > > based file systems where an extent might be broken up between two records > > for some other reason, such as maximum extent length being exceeded. > > Do we really want to expose the filesystem-specific extent-length limits > to userspace? Think of it more as being as literal in our representation of extents as possible. My max extent length was just a (poor) example, meant to illustrate that goal. A better one is extent merging. The Ocfs2 btree code tries pretty hard to merge adjacent extents when they're contiguous. I want to use fiemap in a tool to measure how good a job the extent merging code is doing, especially after we've made bug fixes or enhancements to that area. If the vfs starts to hide these important details from fiemap, then that use case becomes impossible. > In some sense, a block-based filesystem has a maximum extent length of the > blocksize, but it seems totally reasonable to merge contiguous blocks into > a single "extent" for return to userspace. I don't see this significantly > different for ext4, even though it can have extents up to 128MB, or > unwritten extents up to 64MB. I don't know what the answer is for a block based file system. I do know however that we have a compatibility callback there for them and that's the place to implement any block-fs specific features that we want. --Mark -- Mark Fasheh -- 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
