Bug 1314770

Summary: lvcreate can't always create thin pool of maximum size
Product: [Fedora] Fedora Reporter: Marius Vollmer <mvollmer>
Component: lvm2Assignee: Zdenek Kabelac <zkabelac>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: 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
Description of problem:

The lvcreate command fails when trying to create a thin pool of maximum size by giving the exact size (instead of 100%FREE).  After failure, an unexpected volume group of minimal size has been created.

Version-Release number of selected component (if applicable):
lvm2-2.02.132-2.fc23.x86_64

How reproducible:
Always

Steps to Reproduce:

# vgs -o name,vg_extent_size,vg_free_count --units b
  VG   Ext      Free
  vg   4194304B  510

# lvcreate vg -T --thinpool pool -l 510 
  Volume group "vg" has insufficient free space (509 extents): 510 required.

# lvs -o name,lv_size
  LV    LSize
  lvol0 4.00m

# lvremove vg/lvol0
  Logical volume "lvol0" successfully removed

# lvcreate vg -T --thinpool pool -l 509
  Insufficient free space: 254 extents needed, but only 253 available

# lvremove vg/lvol0
  Logical volume "lvol0" successfully removed

# lvcreate vg -T --thinpool pool -l 508
  Logical volume "pool" created.

# lvs -o name,lv_size,lv_metadata_size --units=4194304B
  LV   LSize   MSize 
  pool 508.00U  1.00U

(One extent has disappeared, no?)

Actual results:

As above.

Expected results:

lvcreate succeeds to create a thin pool when given the number of free extents in the volumegroup.

When lvcreate fails, it should not leave an unexpected logical volume behind.

Additional info:

The actual volume group in question is very small, only 2 GiB.  I try with a larger one also.

Using "-L" fails in the same way.

Using "-l 100%FREE" succeeds, but we are using lvcreate as an API, so it would be nice to just pass raw numbers.

Comment 1 Marius Vollmer 2016-03-04 12:40:22 UTC
> After failure, an unexpected volume group of minimal size has been created.

Sorry, an unexpected logical volume is created.

Comment 2 Marius Vollmer 2016-03-04 12:57:04 UTC
> 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"?

Comment 3 Zdenek Kabelac 2016-03-04 13:08:05 UTC
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...

Comment 4 Marius Vollmer 2016-03-04 14:05:58 UTC
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".

Comment 5 Marius Vollmer 2016-03-04 14:10:20 UTC
> 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.

Comment 6 Marius Vollmer 2016-03-04 14:11:48 UTC
Please note that while it might be OK for lvcreate to fail in this case, it should not leave the expected logical volume behind.

Comment 7 Zdenek Kabelac 2016-03-04 14:24:12 UTC
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.

Comment 8 Marius Vollmer 2016-03-04 14:37:07 UTC
(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.

Comment 9 Fedora End Of Life 2016-11-24 15:55:40 UTC
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.

Comment 10 Fedora End Of Life 2016-12-20 19:14:27 UTC
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.