From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 39D357CA0 for ; Thu, 4 Aug 2016 19:49:33 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 96492AC003 for ; Thu, 4 Aug 2016 17:49:29 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by cuda.sgi.com with ESMTP id 57pnqGkQnENYJrHI (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 04 Aug 2016 17:49:27 -0700 (PDT) Date: Thu, 4 Aug 2016 17:49:18 -0700 From: "Darrick J. Wong" Subject: Re: [PATCH v7 00/47] xfs: add reverse mapping support Message-ID: <20160805004918.GY8590@birch.djwong.org> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160804235015.GC16044@dastard> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Dave Chinner Cc: Mark Fasheh , linux-fsdevel@vger.kernel.org, bfoster@redhat.com, xfs@oss.sgi.com, vishal.l.verma@intel.com On Fri, Aug 05, 2016 at 09:50:15AM +1000, Dave Chinner wrote: > On Thu, Aug 04, 2016 at 08:48:45AM -0700, Darrick J. Wong wrote: > > On Wed, Aug 03, 2016 at 07:18:52PM -0700, Mark Fasheh wrote: > > > On Wed, Aug 03, 2016 at 05:58:43PM -0700, Darrick J. Wong wrote: > > > > On Wed, Aug 03, 2016 at 01:55:20PM -0700, Darrick J. Wong wrote: > > > > > On Wed, Aug 03, 2016 at 12:45:36PM -0700, Mark Fasheh wrote: > > > > > > Where can I the patches to enable dedupe_range on xfs? I tested your > > > > > > previous devel branch based on Linux v4.7-rc3 with duperemove > > > > > > (https://github.com/markfasheh/duperemove) and it worked extremely well - > > > > > > even handling some cases that btrfs still has issues with. I actually > > > > > > committed the code to enable xfs support in duperemove so anyone can test on > > > > > > xfs with the dedupe_range patches. > > > > > > > > > > > > I'd gladly test your latest patches by doing my usual 'large' duperemove > > > > > > tests once I can get ahold of the dedupe_range work :) > > > > > > > > > > Your best bets are probably the -experimental trees: > > > > > https://github.com/djwong/linux/commits/djwong-experimental > > > > > https://github.com/djwong/xfsprogs/commits/djwong-experimental > > > > > > > > > > I haven't updated them in a while because I've been busy trying > > > > > to get reverse-mapping (the start of those patchbombs) into 4.8. > > > > > > > > > > Just as a warning, don't put anything critical on those XFS filesystems > > > > > because there's going to be a disk format update between now and the > > > > > next time I post the patches because Dave and I decided to cache the > > > > > block counts for the new btrees in order to speed up mounting. I don't > > > > > anticipate having time to clean up my dev tree and push to github until > > > > > a week or two after the merge window closes. > > > > > > > > That said, all the craziness from the last two weeks (xfs_scrub sprint > > > > and the rmapbt review fixes) are now in the -wtf tree, which /should/ > > > > behave. I've dumped everything there in completely not cleaned up > > > > format, but this does have the AGF btree block counter stuff I talked > > > > about above. > > > > > > > > https://github.com/djwong/linux/commits/djwong-wtf > > > > https://github.com/djwong/xfsprogs/commits/djwong-wtf > > > > > > Fantastic. Don't worry about corrupting data, I've been doing this long > > > enough to know to use this only on scratch partitions for now :) I'm in the > > > middle of a couple other tests but once I'm done there I'll grab those > > > branches and give them another spin. Typically I'm running through 800G-1TB > > > on these (with varying duplicated data percentages). > > > > > > Silly question which I could just answer by looking at the patches - are you > > > reporting FIEMAP_EXTENT_SHARED yet for extents with more than one owner? We > > > use that flag (by comparing SHARED bytes before and after dedupe) to give > > > people an estimate of how much space was saved. I presume figuring the > > > shared state of an extent would be as easy as querying the rmap btree, > > > correct? > > > > Yes, it should report FIEMAP_EXTENT_SHARED. In the past it would > > report exactly which parts of an extent were shared. If a file mapped > > blocks 30-40 and block 35 was shared, it would report 30-34, 35 > > (shared), and 36-40. However, btrfs only reports a single extent > > "30-40 (shared)" so I stopped doing that. > > 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. > > Hence I think what btrfs does is sub-optimal and we shouldn't copy > it. Let's do the right thing with XFS and if people complain it is > different to btrfs then someone can go make btrfs report an accurate > extent map, too. That's probably going to be right after I get a xfstest committed that checks for the XFS behavior and fails on btrfs. :) --D > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs