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