Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2

[Eric Sandeen <sandeen@redhat.com>]

Mark Fasheh wrote:
> Hello,
> 
> 	The following patches are the latest attempt at implementing a
> fiemap ioctl, which can be used by userspace software to get extent
> information for an inode in an efficient manner.
> 
> 	These patches are against 2.6.26-rc3, though they probably apply
> fine against Linus' latest tree. The fs patches are much more complete this
> time around, and the vfs patch has been trimmed down.
> 
> 	An updated version of my ioctl wrapper test program is available at:
> 
>    http://www.kernel.org/pub/linux/kernel/people/mfasheh/fiemap/tests/
> 
> 	A couple of notes regarding the VFS patch:
> 
> 	Firstly, most behavior-changing fm_flags have been removed. We're
> left with SYNC and XATTR now. This is a very good thing because frankly, I
> think fiemap should be targeted as a straight-forward and relatively
> uncomplicated API for exposing extents as they appear on disk. Think "one
> notch above extent-based FIBMAP replacement".

So Mark's gonna hate me for this 'cause I was acting all resigned last
night, but I have to throw this out (sorry Mark!)

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:

1) If you have 8 contiguous 128M extents for a 1G file, currently the
interface will (or may) give you back 8 extents for the entire file,
even though the file is 100% unfragmented, because that reflects the
details of the filesystem's internal accounting.

2) Further, if you ask for a mapping of that file between 100M and 200M
(logical), you will (or may) get back 2 extents between 0M and 256M
because again, that is how the filesystem is tracking the layout internally.

(compare with a simple mapping-only interface which would return a
single range from 0 to 1G, or from 100M to 200M).

Either approach has its merits, depending on what you want the interface
to do I suppose.  Maybe it should even be (gasp) another flag to switch
between one or the other?  (merge & trim extents vs. distinct & full
extents?)

For filesystem debugging work I see the value in returning some details
of the filesystem's internal representation of the layout.  For a
mapping interface, I think it complicates things for the caller.

In the end I can live with either as long as we're explicit about it,
but I think it's worth pointing out.

-Eric