Description of problem: Add a strict no-over-provision mode for lvm thin pools, so that pool data and metadata space cannot run out. Especially with anaconda offering this feature for the root fs, people are going to casually install their systems on thin, and assume that it'll "just work" like lvm has always worked before. In this case, people would be best off if it's impossible for data/metadata space to run out. When enabled over-provisioning, they could be warned to watch out for available space, or everything could be lost. A solution to this would probably be a combination of: - limit the thin lv size to some fraction of the data size - limit the number of thin lvs and snapshots so that given the max size of each, they would not exhaust data space - use a very large metadata size that would be impossible to exhaust given the worst case for the number of lvs set above e.g. picking some random numbers that may be in the ballpark data lv size = 500G metadata lv size = 5G max thin lv size = 50G max number of thin lvs and snapshots = 8 This email is an example where this limit would have helped: http://thread.gmane.org/gmane.linux.lvm.general/14998 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
We need to break this req down some more. What kernel support do you need for this, if any? eg, Would per LV provisioning thresholds which trigger dm events help?
In theory, I don't think any dm or kernel changes would be required. I think lvm could limit the size of lvs and the number of lvs so that the maximum possible space consumed would be less than available space. A similar calculation would be made for the worst case metdata consumption based on the max size and max number of lvs. The metadata lv would be created with a size greater than the worst case. If a user attempted to create an new thin lv or a new snapshot beyond the limits, lvm would report and error, pointing to the no-over-provisioning setting. The user could then change the setting to allow over-provisioning, hopefully seeing the warnings and requirements associated with it (related to dmeventd auto-extension, the consequences of running out of data or metadata space, etc.)
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days