From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ipmail07.adl2.internode.on.net ([150.101.137.131]:10492 "EHLO ipmail07.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751428AbcGMXyM (ORCPT ); Wed, 13 Jul 2016 19:54:12 -0400 Date: Thu, 14 Jul 2016 09:54:08 +1000 From: Dave Chinner To: "Darrick J. Wong" Cc: Brian Foster , linux-fsdevel@vger.kernel.org, vishal.l.verma@intel.com, xfs@oss.sgi.com Subject: Re: [PATCH 040/119] xfs: create helpers for mapping, unmapping, and converting file fork extents Message-ID: <20160713235408.GQ1922@dastard> References: <146612627129.12839.3827886950949809165.stgit@birch.djwong.org> <146612652855.12839.8509289990733155675.stgit@birch.djwong.org> <20160713182825.GC34396@bfoster.bfoster> <20160713184750.GD12567@birch.djwong.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160713184750.GD12567@birch.djwong.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Jul 13, 2016 at 11:47:50AM -0700, Darrick J. Wong wrote: > On Wed, Jul 13, 2016 at 02:28:25PM -0400, Brian Foster wrote: > > On Thu, Jun 16, 2016 at 06:22:08PM -0700, Darrick J. Wong wrote: > > > Create two helper functions to assist with mapping, unmapping, and > > > converting flag status of extents in a file's data/attr forks. For > > > non-shared files we can use the _alloc, _free, and _convert functions; > > > when reflink comes these functions will be augmented to deal with > > > shared extents. > > > > > > Signed-off-by: Darrick J. Wong > > > --- > > > fs/xfs/libxfs/xfs_rmap.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > > > 1 file changed, 42 insertions(+) > > > > > > > > > diff --git a/fs/xfs/libxfs/xfs_rmap.c b/fs/xfs/libxfs/xfs_rmap.c > > > index f92eaa1..76fc5c2 100644 > > > --- a/fs/xfs/libxfs/xfs_rmap.c > > > +++ b/fs/xfs/libxfs/xfs_rmap.c > > > @@ -1123,11 +1123,53 @@ done: > > > return error; > > > } > > > > > > +/* > > > + * Convert an unwritten extent to a real extent or vice versa. > > > + */ > > > +STATIC int > > > +xfs_rmap_convert( > > > + struct xfs_btree_cur *cur, > > > + xfs_agblock_t bno, > > > + xfs_extlen_t len, > > > + bool unwritten, > > > + struct xfs_owner_info *oinfo) > > > +{ > > > + return __xfs_rmap_convert(cur, bno, len, unwritten, oinfo); > > > +} > > > + > > > > Hmm, these all look like 1-1 mappings and they're static as well. Is the > > additional interface for reflink? If so, I think it might be better to > > punt this down to where it is really used (reflink). > > Originally they were, but since the only caller of these functions is > _rmap_finish_one, this whole patch can drop out. > > Later on in reflink, map/unmap/convert for reflinked files get totally > separate "shared" variants, along with corresponding RUI type codes. > > Speaking of which, the shared and non-shared alloc/free/convert > functions are at a high level the same. Each function has 8-10 places > where they differ (mostly in which btree functions they call) and I > wondered -- should I refactor them into a single megafunction that > takes a bunch of function pointers? Use an ops structure containing function pointers. But that can be doen once the code is merged - it doesn't need to be done right away. > It's a little unwieldly to have > so much to pass in, but on the other hand we wouldn't have to maintain > two versions of basically the same code. An ops structure fixes that problem. Cheers, Dave. -- Dave Chinner david@fromorbit.com