3:58 p.m.
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