Changing filesystem resize patterns

It doesn't require anything outside the filesystem to prototype. I did that 5 years ago. The concept works at the filesystem level, but the problem is deployment needs buy-in from the application/storage management layers.

Stratis isn't the solution - it is actually part of the problem. I have proposed this model to the Stratis developers twice in the past ~3 years to address the problems their users have reported with thin provisioned storage pools going ENOSPC unexpectedly under the filesystem and things breaking as a result. There have also been other mechanisms proposed to solve their problems (e.g. directory tree quotas that match pool capacity) but none have been picked up by Stratis. The sparse address space filesystem architecture solves their problem, but it didn't fit neatly into the Stratis storage stack model and so their problems still have not been fixed because we can't fix them at the filesystem level in isolation.

This is what I meant when I said "changes are needed on both sides of the fence". We can make the filesystems work better using thin storage to solve problems that manifest in different environments. However, we can't do that within the constraints of the existing architecture and management models. The architectural changes we need to make result in a storage stack that looks and behaves a bit differently. Management tools need to change to work with architectural changes such as sparse address space devices and device capacity management being promoted to the filesystem level. They'll also need to change to use full sized address space sparse image files for deployments rather than tiny linear block device images - we have all the tools to do this already (qemu-img and using qcow2 as a transport format), so it's largely just a matter of putting all the pieces in place and getting them to work together.

-Dave.