On 7/24/24 4:08 PM, Darrick J. Wong wrote:
> On Wed, Jul 24, 2024 at 10:46:15AM +1000, Dave Chinner wrote:
...
> Counter-proposal: Instead of remapping the AGs to higher LBAs, what if
> we allowed people to create single-AG filesystems with large(ish)
> sb_agblocks. You could then format a 2GB image with (say) a 100G AG
> size and copy your 2GB of data into the filesystem. At deploy time,
> growfs will expand AG 0 to 100G and add new AGs after that, same as it
> does now.
And that could be done oneline...
> I think all we'd need is to add a switch to mkfs to tell it that it's
> creating one of these gold master images, which would disable this
> check:
>
> if (agsize > dblocks) {
> fprintf(stderr,
> _("agsize (%lld blocks) too big, data area is %lld blocks\n"),
> (long long)agsize, (long long)dblocks);
> usage();
> }
(plus removing the single-ag check)
> and set a largeish default AG size. We might want to set a compat bit
> so that xfs_repair won't complain about the single AG.
>
> Yes, there are drawbacks, like the lack of redundant superblocks. But
> if growfs really runs at firstboot, then the deployed customer system
> will likely have more than 1 AG and therefore be fine.
Other drawbacks are that you've fixed the AG size, so if you don't grow
past the AG size you picked at mkfs time, you've still got only one
superblock in the deployed image.
i.e. if you set it to 100G, you're OK if you're growing to 300-400G.
If you are only growing to 50G, not so much.
(and vice versa - if you optimize for gaining superblocks, you have to
pick a fairly small AG size, then run the risk of growing thousands of them)
In other words, it requires choices at mkfs time, whereas Dave's proposal
lets those choices be made per system, at "expand" time, when the desired
final size is known.
(And, you start right out of the gate with poorly distributed data and inodes,
though I'm not sure how much that'd matter in practice.)
(I'm not sure the ideas are even mutually exclusive; I think you could have
a single AG image with dblocks << agblocks << 2^agblocklog, and a simple
growfs adds agblocks-sized AGs, whereas an "expand" could adjust agblocks,
then growfs to add more?)
> As for validating the integrity of the GM image, well, maybe the vendor
> should enable fsverity. ;)
And host it on ext4, LOL.
-Eric
