This exchange made me think it might be wise for Stratis to take a "order of magnitude" parameter when we create a filesystem.

<tgill> Hi <tgill> I’d like to run XFS over a dm-thin device. I’ve heard that XFS is best setup for future potential growth if the thin device has a size of 1 TiB. I think the idea was to avoid provisioning something small and keep extending it. Is this accurate?

<sandeen> the maximum alllocation group (at least for otherwise default geometry) is 1T. So a 32T filesystem would have 32 1T allocation groups

<sandeen> if you had started with, say, a 128g filesystem and grown to 32T, you would have had many, many more allocation groups than optimal

<sandeen> so I imagine that's what "you've heard" <sandeen> does that make sense? <sandeen> so honestly, if you create a 1T filesystej, you'll get 4x256G AGs (modulo other geometries due to storage layout, but 4 AGs is the default), and if you later grow to 32G, you'll actually have 4x as many AGs as you would have if you'd directly mkfs'd 32T

<sandeen> that's probably not a huge deal, but you do end up in a slightly different spot than if you'd started at 32T <sandeen> er, sorry "later grow to 32T" <sandeen> short answer is, don't grow several orders of magnitude.

<tgill> I need to do a little more reading about how allocation groups work, but it makes sense. :-) <tgill> when I run mkfs.xfs on the thin 1T - 547 MiB is consumed by the pool This is XFS meta data?

<sandeen> yes - the metadata itself will take up very little (log, as well) but it will be ampliefied by the thin chunk size