On Wed, May 28, 2008 at 01:42:15PM -0600, Andreas Dilger wrote: > On May 24, 2008 17:01 -0700, Mark Fasheh wrote: > > > 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? Is that really a problem we need to care about? FIEMAP is just a list of offset/len pairs that makes no assumptions about the maximum size of the underlying filesystem's extent size. e.g. The maximum extent size on XFS varies with block size (2^21 * block size) so having the filesystem merge extents will hide the real number of extents in a given range (which is what we actually want exposed). e.g. we know that we have N extents on the inode, but if a FIEMAP only returns N-2 because of merging, then we've got a consistency problem. To fix this, FIECOUNT becomes much more complex however other existing interfaces will still expose conflicting information (e.g. XFS_IOC_FSGETXATTR). Hence I don't think extent merging is a good idea in general for this API. For specific implementations it could be considered (e.g. the block-based filesystem wrappers) but it should not forced on all implementations. 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
