Bug 1323443 - Extending thinpool metadata doesn't extend pmspare
Summary: Extending thinpool metadata doesn't extend pmspare
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.2
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Zdenek Kabelac
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-03 05:11 UTC by prasun.gera
Modified: 2021-09-03 12:49 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-18 17:32:51 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description prasun.gera 2016-04-03 05:11:46 UTC
Description of problem:

I'm seeing the same behaviour as https://www.redhat.com/archives/linux-lvm/2015-April/msg00017.html. I couldn't find an existing entry in bugzilla. Feel free to close this if it's already resolved. 

I haven't looked in detail how auto extension for thinpool metadata works, but I saw that my thinpool metadata was more than 30% full. The thin pool was setup for /home during the OS installation with stock settings in the GUI installer. I distinctly remember that there wasn't an option to specify the metadata size. So I'm hoping that it chose the small size with some auto-extension enabled. 

Anyway, the thinpool metadata size was set to 76M, and since it was getting full pretty fast, I extended it using lvextend. Now there is a disparity in the sizes of metadata and pmspare.

lvs -a -oname,attr,size rhel_foobar
  LV              Attr       LSize  
  home            Vwi-aotz--   9.02t
  home-snapshot1  Vri---tz-k   9.02t
  [lvol0_pmspare] ewi-------  76.00m
  pool00          twi-aotz--   9.07t
  [pool00_tdata]  Twi-ao----   9.07t
  [pool00_tmeta]  ewi-ao---- 304.00m
  root            Vwi-aotz--  50.00g
  swap            -wi-ao----   7.88g
 
vgdisplay rhel_foobar
  --- Volume group ---
  VG Name               rhel_foobar
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  13
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                5
  Open LV               3
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               9.10 TiB
  PE Size               4.00 MiB
  Total PE              2384258
  Alloc PE / Size       2380246 / 9.08 TiB
  Free  PE / Size       4012 / 15.67 GiB
  VG UUID               Nm1pgt-K8EJ-lHaW-tGZj-eczO-NuH5-9I5FEb


The underlying file-system is xfs. Is this a problem ? Are there any remedial steps that I can take ?


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. lvextend -L+152M rhel_foobar/pool00_tmeta

Actual results:
1. Only metadata is extended

Expected results:
pmspare should also be extended ? Or some warning/documentation should be provided if this is not a safe step

Additional info:

Comment 2 prasun.gera 2016-04-03 05:49:31 UTC
I just had a look at /etc/lvm/lvm.conf, and I noticed thin_pool_autoextend_threshold = 100. So the metadata was never going to extend on its own ? That's puzzling. Why does the OS installer such a low value then ?

Comment 4 Zdenek Kabelac 2020-08-24 09:15:02 UTC
(In reply to prasun.gera from comment #2)
> I just had a look at /etc/lvm/lvm.conf, and I noticed
> thin_pool_autoextend_threshold = 100. So the metadata was never going to
> extend on its own ? That's puzzling. Why does the OS installer such a low
> value then ?

lvm2 default configuration is set to NOT auto-extend any LV - as we do not know what for is the free space VG
(same as with old 'thick' snapshots).

So it's always on the machine administrator to decide how can 'eat' space in VG.

Note: this allocation policy should be probably much more advanced like setting 'max' size the pool can grow to - but that's probably a big can a worms.

Anyway - ATM if you want the thin-pool to auto-extend - you need to set threshold to lower value then 100% - from this moment (when monitoring is enabled) thin-pool can 'eat' free space in your VG.

I also believe current version of lvm2 is maintaining size of _pmspare much better and the _pmspace should be upsized to biggest metadata LV in VG (for recovery purpose)

Comment 6 Zdenek Kabelac 2020-11-18 17:32:51 UTC
There have been several fixes already upstream improving extension of _pmspare - but those likely not meet criteria for new release of RH7.


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