Bug 1314770
Summary: | lvcreate can't always create thin pool of maximum size | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Marius Vollmer <mvollmer> |
Component: | lvm2 | Assignee: | Zdenek Kabelac <zkabelac> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 23 | CC: | agk, bmarzins, bmr, dwysocha, heinzm, jonathan, lvm-team, msnitzer, mvollmer, prajnoha, prockai, zkabelac |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-12-20 19:14:27 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
Marius Vollmer
2016-03-04 12:39:32 UTC
> After failure, an unexpected volume group of minimal size has been created.
Sorry, an unexpected logical volume is created.
> I try with a larger one also. Similar results with a 30 GiB volume group: # vgs -o name,vg_extent_size,vg_free_count --units b VG VG Ext Free VG 4194304B 7679 # lvcreate VG -T --thinpool pool -l 7679 Volume group "VG" has insufficient free space (7671 extents): 7679 required. Unfortunately, lcreate doesn't always miscalculate by exactly 2 extents as in comment 0. What would a good way be to calculate the maximum number that can be given to "-l"? Not sure what you trying to achieve - but thin-pool is being build from 2 underlying LVs - one is dataLV and the other is metadataLV. The size of metadataLV is estimated by lvm2 tool based on our 'user-experience' estimation and changes - it's not fixed but at the moment we roughly target to be at most 128MB unless told differently. Then there is hidden sparse 3rd. LV (see lvs -a _pmspare) which is our placeholder within VG to be able to repair thin-pool metadata. (so yep 3 LVs are being made - and size of those extra 2 are not fixed and may change according to our needs). So there is nothing like use 100% just for my data. In fact you should not be even trying to do it this way - you should start with reasonable 'minimal' size of thin-pool and let the thin-pool automatically grow once its space is exhausted/used - so the remaining portion of VG could be used dynamically used for something else. If there is ANY tool expecting some fixed sizes - the tool is doing it wrong. Sizes are under full control of lvm2 - unless explicitly specified on commands line - but in that case you loose crucial feature of lvm2 to manage your volumes in the best way... Okay, I think I get it now. The size of the meta data and potential sparse volume are added to the value given to -l to give the total size, instead of being subtracted to give the data volume size, except when using the %FREE convenience syntax. So it looks like we need to use the %FREE syntax as well as the API when we want to say "take this amount of space and turn it into a thin pool with all your defaults" instead of "make me a thin pool for this much data and use as much extra space as is needed according to your defaults". > Not sure what you trying to achieve
We try to make a super simple UI for thin pool creation where the user inputs a name and indicates the size with a slider. Whacking the slider to the right should result in a maximally big thin pool.
Please note that while it might be OK for lvcreate to fail in this case, it should not leave the expected logical volume behind. The current size logic does apply to some 'final' volume size. So when you use -l #extents - there is going to be some LV which does have this amount of extents (or more depending on strip rounding or so). lvm2 currently doesn't have an option like --totalextents - where you would let lvm2 figure out internal subvolumes to fit totally into given number of extents. With -l%FREE the situation is slight different - here is lvm2 given some 'freedom' and it will try to adapt size to build something as result - and when it fails - it should be mostly seen as a bug (and I think there are quiet a room for improvements - but ATM it's complicated to fix) Also it's really time to move from 'extent' precision - users do not care if the volume is 1 extent bigger or smaller - when you operate in TB. (In reply to Zdenek Kabelac from comment #7) > lvm2 currently doesn't have an option like --totalextents - where you would > let lvm2 figure out internal subvolumes to fit totally into given number of > extents. This would be very useful for us. This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |