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