Bug 1418684
| Summary: | [RFE] Provide a way to create an LV by total size | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jonathan Earl Brassow <jbrassow> | |
| Component: | lvm2 | Assignee: | Zdenek Kabelac <zkabelac> | |
| lvm2 sub component: | Command-line tools | QA Contact: | cluster-qe <cluster-qe> | |
| Status: | CLOSED DEFERRED | Docs Contact: | ||
| Severity: | unspecified | |||
| Priority: | unspecified | CC: | agk, dlehman, heinzm, jbrassow, msnitzer, prajnoha, thornber, zkabelac | |
| Version: | 7.2 | Keywords: | FutureFeature | |
| Target Milestone: | rc | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1899134 (view as bug list) | Environment: | ||
| Last Closed: | 2020-11-18 15:31:41 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 1416885 | |||
| Bug Blocks: | 1899134 | |||
|
Description
Jonathan Earl Brassow
2017-02-02 14:11:56 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. 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? Cloning as upstream issue as bug 1899134 |