Currently, when creating an LV the size specified is the "usable" size. Metadata devices that need to be created are extra. So, if you have 500G left and you specify a size of 500G for your LV, the creation will fail if a metadata area is required.
Let's create an option (or a behavioral switch in lvm.conf) that causes the metadata areas to be included in the size specified - i.e. everything fits into the size specified by the user.
--- Additional comment from Red Hat Bugzilla Rules Engine on 2017-02-03 12:26:10 UTC ---
Since this bug report was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
--- Additional comment from Zdenek Kabelac on 2017-02-09 11:05:49 UTC ---
The correct solution here is to rewrite/extend allocator support to handle multiple allocations at once (at this moment i.e. thin-pool creation basically overload 'mirror + mirror-log' allocation).
As a 'bypass' temporary approximation short-term fix we could possibly convert such given size to our 'percentage' allocation logic which is able/allowed to decrease allocated request if there is not enough room).
However this attempt is quite imperfect as 'too big allocation' preceding in the row of multi-allocators call will simply kill the command even though there could have been solution for given '--totalsize' request.
ATM I'm not sure we can manage even the 'short-term' fix request to 7.4 properly as the percentage allocation is not working yet in all cases - see bug 1416885.
Preferable order of fixes would need this one to work first.
--- Additional comment from Zdenek Kabelac on 2017-02-16 14:17:43 UTC ---
Let's put here some notes collect from discussion.
The existing 'percentage' allocation which is documented as 'upper-limited' is actually not exactly 'upper-limited' documentation somewhat lost the 'word' 'approximately upper-limited'.
So there is no existing code to provide this functionality without further change on existing code paths.
Next outcome is - we have -l LogicalExtent - which have then some 'physical extentd' backend - so it seem appropriate matching options would be:
giving hard upper-limit for allocations - but that's certainly huge work especially when you can combine all things together.
We even already have '--physicalextent' shorcut but it's using '-E'.
So one can already see a problem:
Overall goal then seems to be pretty clean - unlike today we figure from given logical size/extent internal total number of physical extents - we need to support opposite direction of this process and make a best use of given physical space to create as big LV as possible.
This is surely out of scope of 7.4 for anything else but linear LVs - which do seem to be reasonable easy to try to fit in :) as there almost 1:1 mapping, just stripe needs different rounding.
So we could try to implement creation of some LV types and over the time add more - but not sure it's worth to implement this in such pieces....
Any other opinion?