Stratis 3.0 allows the "logical size" of a filesystem to be set as well as a "no-overprovisioning" flag for a pool. These can be used together to prevent the unpleasant effects of running out of blocks to allocate for operations where XFS / applications can't handle that well.

(This is where the decision of Stratis to re-use existing technology leaks out of its abstraction. Ideally, XFS and thin provisioning would work flawlessly together, but they don't.)

We could maybe expose this as a per-pool "Manage filesystem sizes" flag.  When on, we show logical sizes of filesystems and require the user to specify them when creating new ones. A Stratis pool would essentially behave like a LVM2 volume group with only "linear" volumes in it.

Cockpit would not allow creation of filesystems that are too big for the pool (by capping the size slider to the maximum, or disabling the button altogether). We might need help from the Stratis API to determine the maximum size of a new filesystem, or maybe this is trivial to compute from the pool usage numbers.

Switching a existing pool into "Manage filesystem sizes" mode might be difficult. We might need to ask the user for the sizes of existing filesystems and shrink them, which isn't really possible with XFS, yada yada. So maybe this can only be set "on" when creating a pool. Switching it off might be easier.

Can Stratis grow existing filesystems? If so, we should support that as well in Cockpit.