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