On Thu, Jul 14, 2016 at 09:54:08AM +1000, Dave Chinner wrote:
> 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.
I actually did mean an ops structure; passing in function pointers as
args is wayyyy fugly... but I'd considered that making a bunch of small
functions + a struct might not be much better. :)
--D
>
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
|