XFS info

[Todd Gill]

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

[Andy Grover]

On 06/09/2017 01:58 PM, Todd Gill wrote:
>  
>  
>  This exchange made me think it might be wise for Stratis to take a
>  "order of magnitude" parameter when we create a filesystem. 
This raises a bunch of questions for me. What exactly are the 
consequences of "over-growing" a filesystem? A greater number of AGs 
than if it were initially created for that size, ok, but what does that 
mean? A performance hit or does the fs actually have reduced integrity 
or something? If we do want to avoid over-growing a filesystem, what 
should Stratis do when a "fully grown" filesystem needs more space?

Do XFS AGs make a difference when the fs is thin-provisioned?

Should we be trying to minimize the initial number of AGs? We should 
only be growing the filesystem in multiples of the initial per-AG size?

Should we be specifying specific values to mkfs_xfs instead of relying 
on its defaults?

What can we do to minimize the overhead each empty filesystem takes, 
both in how we mkfs_xfs, as well as how we pick the best thinpool block 
size?

This junction between thin and the filesystem is biggest known weak spot 
inherent in Stratis's design. We're going to have to put a fair amount 
of work in understanding the tradeoffs here pretty deeply in order to 
balance things properly.

Thoughts?

-- Andy