Re: [PATCH 040/119] xfs: create helpers for mapping, unmapping, and converting file fork extents

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <darrick.wong@xxxxxxxxxx>
> > > ---
> > >  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@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux