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:

quoted

On Thu, Jun 16, 2016 at 06:22:08PM -0700, Darrick J. Wong wrote:

quoted

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 <redacted>
---
 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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs