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