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