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. 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.
- Ted
