What should the feature do:

Allow the thin pool to create LVs "endlessly".

func (p *thinPoolAdapter) Free(ctx context.Context) (uint64, error) internal/lvmd/pool.go:42:
Uses Usage method, and FreeBytes from internal/lvmd/command/lvm.go:291 .

The FreeBytes is not taking into account the Data%, but instead a logic based on configurable overprovisionRatio.

I've checked the design and seems to me that actual use case for overprovisionRatio parameter is updating the capacity for scheduling decisions?

I'm wondering if is it possible to make the overprovisioningRatio parameter optional?
As of capacity calculus: take the Data% into account and place the actual pool usage.
Additionally as a user I can use affinity rules to spread my workload among nodes.

Given the change is acceptable I can work on this PR.

What is use case behind this feature:

• I would expect the LVM-thinpool-backed storage to behave, well... like the LVM. The LVM doesn't introduce virtual overprovisioning parameter, it allows to create thin LVs "endlessly" (as long they don't exhaust the underlying data storage)
• as a TopoLVM user I have a ton of almost empty LVs and I can't schedule new ones (snapshots of rarely changing LV). The capacity awareness works in my disadvantage here.