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 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.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
