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
|