On Fri, Aug 05, 2016 at 02:57:16PM +0300, Artem Bityutskiy wrote: > On Fri, 2016-08-05 at 20:49 +1000, Dave Chinner wrote: > > On Fri, Aug 05, 2016 at 10:01:14AM +0300, Artem Bityutskiy wrote: > > > > > > On Fri, 2016-08-05 at 09:50 +1000, Dave Chinner wrote: > > > > > > > > I'd much prefer that fiemap gives exact information about shared > > > > extents. FIEMAP is a diagnostic tool and as such we need it to > > > > accurately reflect the exact extent map of the inode being > > > > queried > > > > so we aren't mislead about the layout of the file during trouble > > > > shooting. > > > > > > Hi Dave, you are right, and here is a side note: we were using > > > FIEMAP > > > for optimizing image deployment in production, so it is a > > > diagnostic > > > tool and more. > > > > Yay, data corruption ahoy! > > > > Hasn't /anyone/ listened to the repeated statements from fs > > developers that FIEMAP is not a safe method of optimising data > > copying? > > Yes, which is kind of sad from the user's perspective. No, it's not. FIEMAP was not ever intended as a user facing tool. What is sad is that the application developers are not listening to what they are told. It's got to be almost 5 years ago we thought we put this to bed after a raft of "cp causing data corruption" bugs were reported by users and that was caused by new "FIEMAP optimised date copies". We implemented SEEK_DATA/SEEK_HOLE - which is coherent with page caceh state - to allow application developers to optimise their sparse data copies without having to scan data. Use that instead, please. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
