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@xxxxxxxxxxxxx
