From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:19377 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933719AbcHEW0c (ORCPT ); Fri, 5 Aug 2016 18:26:32 -0400 Date: Sat, 6 Aug 2016 08:26:26 +1000 From: Dave Chinner To: Artem Bityutskiy Cc: "Darrick J. Wong" , Mark Fasheh , linux-fsdevel@vger.kernel.org, vishal.l.verma@intel.com, bfoster@redhat.com, xfs@oss.sgi.com Subject: Re: [PATCH v7 00/47] xfs: add reverse mapping support Message-ID: <20160805222626.GK16044@dastard> References: <146907695530.25461.3225785294902719773.stgit@birch.djwong.org> <20160803194536.GJ5316@wotan.suse.de> <20160803205520.GQ8590@birch.djwong.org> <20160804005843.GJ8593@birch.djwong.org> <20160804021852.GK5316@wotan.suse.de> <20160804154845.GV8590@birch.djwong.org> <20160804235015.GC16044@dastard> <1470380474.2311.71.camel@gmail.com> <20160805104950.GF16044@dastard> <1470398236.2311.89.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1470398236.2311.89.camel@gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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@fromorbit.com