Re: [PATCH 1/5] vfs: vfs-level fiemap interface

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com