Bug 1278074
Summary: | [RFE] please provide a way to specify maximum number of extents taken from PVs in lvcreate | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Vratislav Podzimek <vpodzime> |
Component: | lvm2 | Assignee: | Joe Thornber <thornber> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | agk, bmarzins, bmr, dlehman, dwysocha, heinzm, jbrassow, jonathan, lvm-team, msnitzer, prajnoha, vtrefny, zkabelac |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-10-07 09:52:45 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: |
Description
Vratislav Podzimek
2015-11-04 16:24:24 UTC
In some way we already do support this kind of 'limits' e.g.: /dev/sda:0-499 is exactly what allocator can use - i.e. if you create a map of 'free' extents you pass in what allocated will be able to take and will stop when it fails to find space. The main issue here is - there is possibly misunderstanding of lvm2 goal and Blivet goal. Probably needs wider discussion - but this Blivet/Anaconda requirement looks more like it wants to 'overrule' what lvm2 as volume manager does. The purpose of lvm2 is - to make decision according to available space - which could be used in various ways according to configured policy. On the other side there is Blivet/Anaconda with assumption all 'space' is equal and is needed purely for user-visible volumes - but many targets do require also user-invisible i.e. metadata,spare volumes. I assume we need wider discussion first about the goals what user should actually be doing and how the communication with lvm2 should look-like. IMHO Blivet cannot try to 'play on' lvm2 and 'pretend' it knows what happens when complex device stack is going to be created - it's illusionary to create stack of 10 devices ahead with sector precision and having there 'Processed' button and expect it will happen exactly this way. (Lvm2 now supports more complex targets then plain & simple linear/stripe LVs - for those you can mostly do such calculation...) Outline: 1) Determine completely suitable command line syntax extensions; 2) Add code to parse these command line extensions; 3) Determine how to encode the new constraints to pass to the allocation code; 4) Maintain the remaining quotas available for each device as space is selected within the allocation code; 5) At each point potential space on a device is considered, if its length exceeds the remaining quota for that device, reduce it to fit. Command extensions to consider might specify absolute maximum allocations for each device, or might specify relative requirements (50% from disk A and 50% from disk B). After some more discussion, it seems it's targeting this use-case: pvchage --addtag slow pv1 pv2 pv3 pvchage --addtag fast pv4 pv5 lvcreate -L10 vg @slow lvcreate -L20 vg @fast Somehow we are not quite good at advertising this capability in man pages. > pvchage --addtag fast pv4 pv5
pvchange
|