Re: Maximum height of rmapbt when reflink feature is enabled

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Tue, Dec 01, 2020 at 06:42:51PM +0530, Chandan Babu R wrote:
> On Tue, 01 Dec 2020 09:03:47 +1100, Dave Chinner  wrote:
> > On Mon, Nov 30, 2020 at 11:26:05AM -0800, Darrick J. Wong wrote:
> > > On Mon, Nov 30, 2020 at 02:35:21PM +0530, Chandan Babu R wrote:
> > > > I have come across a "log reservation" calculation issue when
> > > > increasing XFS_BTREE_MAXLEVELS to 10 which is in turn required for
> > > 
> > > Hmm.  That will increase the size of the btree cursor structure even
> > > farther.  It's already gotten pretty bad with the realtime rmap and
> > > reflink patchsets since the realtime volume can have 2^63 blocks, which
> > > implies a theoretical maximum rtrmapbt height of 21 levels and a maximum
> > > rtrefcountbt height of 13 levels.
> > 
> > The cursor is dynamically allocated, yes? So what we need to do is
> > drop the idea that the btree is a fixed size and base it's size on
> > the actual number of levels iwe calculated for that the btree it is
> > being allocated for, right?
> > 
> > > (These heights are absurd, since they imply a data device of 2^63
> > > blocks...)
> > > 
> > > I suspect that we need to split MAXLEVELS into two values -- one for
> > > per-AG btrees, and one for per-file btrees,
> > 
> > We already do that. XFS_BTREE_MAXLEVELS is supposed to only be for
> > per-AG btrees.  It is not used for BMBTs at all, they use
> > mp->m_bm_maxlevels[] which have max height calculations done at
> > mount time.
> > 
> > The problem is the cursor, because right now max mp->m_bm_maxlevels
> > fits within the XFS_BTREE_MAXLEVELS limit for the per-AG trees as
> > well, because everything is limited to less than 2^32 records...
> > 
> > > and then refactor the btree
> > > cursor so that the level data are a single VLA at the end.  I started a
> > > patchset to do all that[1], but it's incomplete.
> > > 
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?h=btree-dynamic-depth&id=692f761838dd821cd8cc5b3d1c66d6b1ac8ec05b
> >
> 
> Darrick, I will rebase my "Extend data fork extent count field" patches on top
> your patch with required fixes applied. Please let me know if you have any
> objection to it.

You might want to wait a day or two, because I decided to get rid of
XFS_BTREE_MAXLEVELS entirely as part of making the cursors dynamically
sized.

--D

> > Yeah, this, along with dynamic sizing of the rmapbt based
> > on the physical AG size when refcount is enabled...
> > 
> > And then we just don't have to care about the 1kB block size case at
> > all....
> > 
> 
> -- 
> chandan
> 
> 
>