Hi!
One thing I'ld like to mention is that in Stratis 3.0, you'll
be able to set the size of the filesystem at the command-line,
although the default size will remain 1 TiB. There are some caveats;
it's not a good idea to grow an xfs filesystem by more than about 8
times as the metadata layout is calculated for the original size specified.
But, while this might be useful to others, I don't think it's really
all that relevant to your case. The amount of space allocated by the
thinpool for your data should really correspond to your filesystem
usage, which is only about 1 TiB.
Generally speaking, Stratis responds to devicemapper events, including
the low water event. It then does an analysis of your pool, including the
filesystems, to determine if any adjustment should be made.
Can you show us the output of the "stratis pool list" command? That
should show both the amount of space actually used (by your data +
Stratis metadata) the total size as understood by Stratis, and the amount
that Stratis interprets as free.
From what you tell me, I think it's possible that, during I/O, the low water
mark is reset multiple times by stratisd, and also crossed multiple times,
triggering repeated re-evaluations of the pool and filesystem states, which
perhaps then result in no action, but cause the slow I/O that you mentioned.
You can't prevent Stratis from doing this check, without accepting a patch and
recompiling. This check is there to prevent running out of space, so it's
not optional. It is our present goal to make these checks more effective and less intrusive.
In fact, we just today merged a PR[1] which inaugurates
our development efforts on thinpool and filesystem management improvements.
Thanks for getting in touch,
- mulhern