RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1418684 - [RFE] Provide a way to create an LV by total size
Summary: [RFE] Provide a way to create an LV by total size
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Zdenek Kabelac
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On: 1416885
Blocks: 1899134
TreeView+ depends on / blocked
 
Reported: 2017-02-02 14:11 UTC by Jonathan Earl Brassow
Modified: 2021-09-03 12:50 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1899134 (view as bug list)
Environment:
Last Closed: 2020-11-18 15:31:41 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jonathan Earl Brassow 2017-02-02 14:11:56 UTC
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.

Comment 2 Zdenek Kabelac 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.

Comment 3 Zdenek Kabelac 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?

Comment 4 Zdenek Kabelac 2020-11-18 15:31:41 UTC
Cloning as upstream issue as bug 1899134


Note You need to log in before you can comment on or make changes to this bug.