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