Bug 1097948 - RFE: 'lvs --all' should report "Meta%" value
Summary: RFE: 'lvs --all' should report "Meta%" value
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: 20
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Alasdair Kergon
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-14 23:30 UTC by John Call
Modified: 2014-05-15 07:35 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-05-15 07:35:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description John Call 2014-05-14 23:30:54 UTC
Description of problem:
  thin-provisioned logical volumes are in danger of exhausting metadata space when the underlying hardware is changed.  For example, when new storage is attached and the number of PV extents increases for the thin pool.  The danger is not easily perceived when looking at the output of "lvs --all".  I'm suggesting that the output of "lvs --all" be ammended to include two additional fields: metadata_percent and lv_metadata_size

Actual results:

[jcall@jcall-laptop ~]$ sudo lvs --all
  LV              VG     Attr       LSize   Pool   Origin Data%  Move Log Cpy%Sync Convert
  home            rootvg Vwi-aotz--  97.66g pool00          2.25                          
  images          rootvg Vwi-aotz-- 488.28g pool00         13.52                          
  [lvol0_pmspare] rootvg ewi-------  80.00m                                               
  pool00          rootvg twi-a-tz-- 634.77g                11.61                          
  [pool00_tdata]  rootvg Twi-ao---- 634.77g                                               
  [pool00_tmeta]  rootvg ewi-ao----  80.00m                                               
  root            rootvg Vwi-aotz--  48.83g pool00         11.24                          
  swap            rootvg -wi-ao----   7.81g                                               


Expected results:
[jcall@jcall-laptop ~]$ sudo lvs --all -o lv_name,vg_name,lv_attr,lv_size,pool_lv,origin,data_percent,metadata_percent,lv_metadata_size,move_pv,mirror_log,copy_percent,convert_lv
  LV              VG     Attr       LSize   Pool   Origin Data%  Meta%  MSize  Move Log Cpy%Sync Convert
  home            rootvg Vwi-aotz--  97.66g pool00          2.25                                        
  images          rootvg Vwi-aotz-- 488.28g pool00         13.52                                        
  [lvol0_pmspare] rootvg ewi-------  80.00m                                                             
  pool00          rootvg twi-a-tz-- 634.77g                11.61   6.25 80.00m                          
  [pool00_tdata]  rootvg Twi-ao---- 634.77g                                                             
  [pool00_tmeta]  rootvg ewi-ao----  80.00m                                                             
  root            rootvg Vwi-aotz--  48.83g pool00         11.24                                        
  swap            rootvg -wi-ao----   7.81g                                                             


Additional info:
  I had an unfortunate incident that resulted in filesystem corruption due to this.  Not being able to immediately see the utilization / allocated space of the metadata LV compounded the frustration.  Additional details were posted at https://ask.fedoraproject.org/en/question/46400/why-dont-thin-provisoned-pools-alert-users-when-they-fill-up/

Comment 1 Alasdair Kergon 2014-05-15 07:23:47 UTC
Space is at a premium.  Meta% should be sufficient.

You can customise the list of fields in the report section of lvm.conf.

Comment 2 Alasdair Kergon 2014-05-15 07:28:33 UTC
BTW lvs -v should show that column already

Comment 3 Alasdair Kergon 2014-05-15 07:35:27 UTC
Changed for next release (rawhide).  Won't backport specifically to f20, but if we do update the package there (which is likely at some point) it'll pick up the change.

https://git.fedorahosted.org/cgit/lvm2.git/patch/?id=5684cfcb1c13129b70ddaf1ee4df95e08bc551a9


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