Re: [PATCH 6/6] xfs: don't zap bmbt forks if they are MAXLEVELS tall
"Darrick J. Wong" <[email protected]>
| Newsgroups | org.kernel.vger.linux-xfs,org.kernel.vger.stable |
|---|---|
| Message-ID | <20260714164019.GE7398@frogsfrogsfrogs> |
On Tue, Jul 14, 2026 at 08:16:52AM +0200, Christoph Hellwig wrote: > On Mon, Jul 13, 2026 at 11:07:30PM -0700, Darrick J. Wong wrote: > > From: Darrick J. Wong <[email protected]> > > > > LOLLM noticed a discrepancy between the bmbt level checks in the libxfs > > bmbt code vs. the inode repair code. We do actually allow a bmbt root > > that proclaims to have a height of XFS_BM_MAXLEVELS. > > Looks good: > > Reviewed-by: Christoph Hellwig <[email protected]> > > I guess we need a test that actually creates such a deep tree. But > we'll probably run out space / extents before.. The bmapinflate command in xfs_db does this by writing a new bmap btree with as many mappings pointing to the same "reflinked" block as you ask. The only problem is that to hit maxlevels, you need to create a 1k fsblock filesystem and then bmapinflate 2^54 records, which will take a long time and require much memory. Back in the day when Chandan was working on nrext64 I tried this and it took 2 days and 400G of RAM to write the huge bmap btree out to disk and generate the appropriate rmap/reflink btrees. --D