Stratis would like to support pools with 1000+ PVs and 1M+ LVs. So many are desired because we may want 3-5K primary thin volumes on the pool, but also desire periodic auto-snapshotting capabilities, which then could result in large numbers of secondary read-only LVs to be created frequently, and these need to be tracked somehow.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
This request is more or less beyond the scope of lvm2 itself.
Supportability of using a single thin-pool with 1K+ LVs running them moreover at the same time is ATM rather illusion.
Thin-pool target works optimally for tens of volumes activates at one time.
Thin-pool metadata size is strictly limited to 16GB - and we know users are able to fill even these size with low number of volumes.
Risk of loosing very huge amount of data in case there would be metadata damage is way too high above any sensible limits.
We are not aware of any user requirements even asking for support such use-case.