On Fri, Aug 31, 2018 at 12:28:13PM +1000, Dave Chinner wrote:

On Thu, Aug 30, 2018 at 11:31:48AM -0700, Darrick J. Wong wrote:

quoted

From: Darrick J. Wong <redacted>

Make it so that we can actually store btree records in the inode
core (i.e. enable bb_level == 0) so that the rtrmapbt can do this.

Signed-off-by: Darrick J. Wong <redacted>

So this is so you don't need XFS_DINODE_FMT_RMAP_EXTENTS/BTREE 
inode fork types, right? i.e. there just XFS_DINODE_FMT_RMAP to
indicate it's an rmap tree in the fork?

Yep.

Could this code be used by the data fork, too? Sure, we need to
keep the on-disk fork format info the same, but we could use this to
kill the special BMDR formatting code it currently uses, right?

Hmm.  FMT_EXTENTS uses di_nextents to count the number of records in the
data fork area, whereas FMT_BTREE stores the number of records in the
bmbt root in the data fork area, followed by bmbt keys/ptrs.  I imagine
you could make the formats share code, but you'd have to special case
how much btree header gets written into the data fork area.

The maximum number of bmbt records that can fit in the data fork area
(factoring in alignment requirements) actually does depend on whether or
not we have to allocate space for the root block record count.

Might be worth deeper investigation...

(FWIW, FMT_RMAP always stores the number of root block records in the
data fork area, since it doesn't affect the max record count.)

--D

(just trying to get an idea of whether we'll have to maintain two
bits of code that do essentially the same thing forever)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com