Re: Ext4 fiemap implementation

[Dave Chinner <david@fromorbit.com>]

On Wed, Jun 13, 2018 at 01:04:53AM -0400, Theodore Y. Ts'o wrote:
> On Wed, Jun 13, 2018 at 01:32:04PM +1000, Dave Chinner wrote:
> > > 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).
> 
> As far as I know cp is working with the FIEMAP behavior as implemented
> by ext4 and xfs w/o any problems.

It is, apart from the inherent raciness of using FIEMAP to find
holes and the fact that it won't detect cached data over unwritten
extents....

> Given that ext4 and xfs have been
> doing different things for a *very* long time now, in that sense the
> horse has already bolted.  There may be some applications that
> expecting things the way ext4 has implemnted FIEMAP (and which is
> either allowed or required by the documentation -- I read it as
> mandated; others think it's a "you can do it either way"); and there
> may be some applications that are expecting things the way XFS has
> historically implemented FIEMAP.
> 
> So my proposal was to change the docs to make it clear that Eric
> Sandeen's reading (that either way is fine) is the correct
> interpretation.

Ok, we're saying the same things - it wasn't clear to me that your
proposal was to document both behaviours as valid...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com