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: --physicalextent --physicalsize 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: -L --size -l --extents -? --physicalsize -E --physicalextent 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?