KubeSAN will have thousands of thin pools in one shared VG, and each thin pool will have on average 1-2 thin volumes. Because it's a shared VG, use of the thin pools will be spread across a number of machines, so they do not all need to be used by a single machine. With thousands of thin pools, the VG metadata text becomes large and time consuming to process, which will ultimately create a limit on how many thin pools can be created in one VG. The large majority of the slowness, which is the focus of this issue, comes when an lvm command makes a copy of the metadata in memory to use in a subsequent activation step. The copying method is to export the binary VG structure to a text representation, and then reimport the text representation back into a VG structure. In between the binary and text representations, the dm_config data structure is used. Parsing large metadata text into the dm_config structure is very slow and inefficient. Multiple options are being investigated to improve this, both long term and near term.