Re: Ext4 fiemap implementation

[Dave Chinner <david@fromorbit.com>]

On Tue, Jun 12, 2018 at 11:06:01PM -0400, Theodore Y. Ts'o wrote:
> On Wed, Jun 13, 2018 at 01:52:03AM +0200, Mark Fasheh wrote:
> > > 
> > > So, you are saying iomap implementation violates FIEMAP specs?
> > 
> > Does iomap do this or just XFS? At any rate, the doc should be read
> > as Ted suggests: '"Extents returned mirror those on disk" as meaning
> > that the ext4 behavior is *mandated* by the docs.'
> > 
> > So anything that's mainipulating the returned extents solely to
> > 'fit' them into a request is wrong.
> 
> Well, or the FIEMAP specs could be changed.  If I recall correctly the
> FIEMAP implementation by the various file systems predates the
> documentation.  I suspect whoever wrote the docs looked at the
> ext2/ext3/ext4 implementation and used that to write the
> documentation.  If other file systems were doing something else, I'd
> be in favor of allowing either behavior, since userspace programs who
> care will need to accomodate either behavior.  Fortunately, I suspect
> it matters for very few (if any) userspace programs.

The horse has bolted - we can't redefine the expected behaviour as
that might break apps like cp (yes, it's still using FIEMAP for
sparse file optimisations).

IIRC, extended range reporting wasn't even intended for expanding
normal extents the way ext4 is reporting them - it was intended to
allow reporting of mappings where the calculation of exact
logical->physical mappings (i.e. trimming to the user specified
logical range) was too complex or prohibitively expensive. e.g.
compressed extents (FIEMAP_EXTENT_ENCODED) where we may know the
logical offset range of the physical extent, but we don't know the
exact mapping of logical offsets within the physical extent without
actually reading and decoding the physical extent.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com