On 7/24/24 5:12 PM, Darrick J. Wong wrote: > On Wed, Jul 24, 2024 at 05:06:58PM -0500, Eric Sandeen wrote: >> On 7/21/24 6:01 PM, Dave Chinner wrote: >>> +The solution should already be obvious: we can exploit the sparseness of FSBNO >>> +addressing to allow AGs to grow to 1TB (maximum size) simply by configuring >>> +sb_agblklog appropriately at mkfs.xfs time. Hence if we have 16MB AGs (minimum >>> +size) and sb_agblklog = 30 (1TB max AG size), we can expand the AG size up >>> +to their maximum size before we start appending new AGs. >> >> there's a check in xfs_validate_sb_common() that tests whether sg_agblklog is >> really the next power of two from sb_agblklog: >> >> sbp->sb_agblklog != xfs_highbit32(sbp->sb_agblocks - 1) + 1 >> >> so I think the proposed idea would require a feature flag, right? >> >> That might make it a little trickier as a drop-in replacement for cloud >> providers because these new expandable filesystem images would only work on >> kernels that understand the (trivial) new feature, unless I'm missing >> something. > > agblklog and agblocks would both be set correctly if you did mkfs.xfs -d > agsize=1T on a small image; afaict it's only mkfs that cares that > dblocks >= agblocks. Yes, in a single AG image like you've suggested. In Dave's proposal, with multiple AGs, I think it would need to be handled. -Eric > --D > >> -Eric >> >
