Bug 1279246 - Cannot resize spare LV (for thin pool repair)
Cannot resize spare LV (for thin pool repair)
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: LVM and device-mapper development team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-11-08 15:37 EST by Mike Gerber
Modified: 2015-11-08 16:36 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-08 15:49:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mike Gerber 2015-11-08 15:37:18 EST
Description of problem:

I cannot resize a spare LV (i.e. lvol0_pmspare) using lvresize once it was created:

 $ sudo lvresize -L+10m vg-rowling/lvol0_pmspare
 Can't resize internal logical volume lvol0_pmspare
 Run `lvresize --help' for more information.

As I understand it, the spare needs to be at least as large as the largest thin pool metadata LV, which, in my case, is now larger than the spare:

 $ sudo lvs -a
   LV              VG         Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
   home            vg-rowling Vwi-aotz-- 30.00g pool00        65.82                                  
   [lvol0_pmspare] vg-rowling ewi------- 20.00m                                                      
   pool00          vg-rowling twi-aotz-- 40.00g               67.57  40.37                           
   [pool00_tdata]  vg-rowling Twi-ao---- 40.00g                                                      
   [pool00_tmeta]  vg-rowling ewi-ao---- 32.00m                                                      
   root            vg-rowling Vwi-aotz-- 10.00g pool00        72.82                                  
   swap            vg-rowling -wi-ao----  4.00g       

Another user had the the same problem: http://comments.gmane.org/gmane.linux.lvm.general/15127 -- Zdenek Kabelac asked the user to create a Bugzilla ticket. However, this ticket seems to be the first about this issue.

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

 $ rpm -q lvm2; uname -r

How reproducible:
Steps to Reproduce:

1. Create a smaller thin pool
2. Resize the metadata LV i.e lvresize -L+12m vg-foo/pool00_tmeta
3. Try to resize the spare LV i.e. lvresize -L+1m vg-foo/lvol0_pmspare

Actual results:

 $ sudo lvresize -L+10m vg-rowling/lvol0_pmspare
 Can't resize internal logical volume lvol0_pmspare
 Run `lvresize --help' for more information.

Expected results:

 I expect that the spare LV can be resized.

Additional info:

Comment 1 Zdenek Kabelac 2015-11-08 15:49:37 EST
_pmspare  is lvm2 private LV -  fully maintained by lvm2.

So it's not meant to be used by a user in any way.

However if you have reached state where  _pmspare is smaller then _tmeta, _cmeta  - this is likely a problem - lvm2 should handle this - unless
asked to not do that - but there are currently couple known to me bugs in this area, and in fact we might probably move to higher space requirements for _pmspare:  2 * meta_size

So this bug will be closed as this is expected behaviour - but feel free to open new bugs for sequences where lvm2 missed to size-up _pmspare LV itself.
Comment 2 Mike Gerber 2015-11-08 16:36:05 EST
FWIW, creating another pool with --poolmetadatasize resized the spare LV, while lvresize on the old pool's metadata LV did not.

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