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