Re: [RFC][PATCH 0/5] Fiemap, an extent mapping ioctl

[Dave Chinner <david@fromorbit.com>]

On Wed, May 28, 2008 at 10:04:19AM -0700, Joel Becker wrote:
> On Wed, May 28, 2008 at 10:02:01AM -0600, Andreas Dilger wrote:
> > On May 27, 2008  13:31 -0700, Joel Becker wrote:
> > > 	Provide generic_fiemap_fiecount() that does the operation in
> > > terms of ->fiemap().  Then filesystems like ocfs2 can just do .fiecount
> > > = generic_fiemap_fiecount.
> > > 	I agree with Christoph that it seems a bit overloaded when done
> > > as a special case of FIEMAP.
> > 
> > The question is whether there are any (or many) filesystems that will NOT
> > implement ->fiecount() as a wrapper of ->fiemap()?  At that point the
> > "simplification" of the API means that there is actually more code and
> > layers being called for the simple version.
> > 
> > I'm not saying I'm against having a FIECOUNT ioctl, we're probably just
> > going to use an updated filefrag like everyone else, but it doesn't seem
> > like a net reduction in code anywhere.
> 
> 	It's not about net reduction of code.  It's about a readable and
> understandable interface.  "Pass this array of extent structures we'll
> ignore if you set this special flag" is pretty ugly.  Calling FIECOUNT
> separately is nice.  How it is implemented in the kernel is a whole
> 'nother ball of wax - maybe we don't have ->fiecount() and always
> implement FIECOUNT in terms of a ->fiemap() walk.  Doesn't matter.

XFS has XFS_IOC_FSGETXATTR which can return the number of extents
on an inode. It's a total count, not a range count, so it's a bit
different to FIECOUNT and as such does not require walking the
extent list to retrieve (extent count is in the inode itself).

It's still not that straight forward as you have to encode count,
offset and length into a structure to pass into the ioctl. i.e.
is it really that much simpler and cleaner than just adding a
extra flag to FIEMAP?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com