Bug 431760 - lvm delete message calulates the number of volumes incorrectly
lvm delete message calulates the number of volumes incorrectly
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: lvm2 (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: Peter Rajnoha
Corey Marthaler
:
: 465168 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-06 15:01 EST by Corey Marthaler
Modified: 2010-01-11 22:52 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 07:57:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Corey Marthaler 2008-02-06 15:01:35 EST
Description of problem:

[root@grant-03 ~]# vgremove mirror_sanity
Do you really want to remove volume group "mirror_sanity" containing 8 logical
volumes? [y/n]:          

There are really one 2 volumes, not 8, they just both happen to be mirrors.

[root@grant-03 ~]# lvs
  LV             VG            Attr   LSize  Origin Snap%  Move Log            
    Copy%  Convert
  LogVol00       VolGroup00    -wi-ao 72.44G
  LogVol01       VolGroup00    -wi-ao  1.94G
  resync_nosync  mirror_sanity mwi-a-  2.00G                   
resync_nosync_mlog  100.00
  resync_regular mirror_sanity mwi-a-  2.00G                   
resync_regular_mlog  10.55


[root@grant-03 ~]# lvs -a -o +devices
  LV                        VG            Attr   LSize  Origin Snap%  Move Log 
               Copy%  Convert Devices
  LogVol00                  VolGroup00    -wi-ao 72.44G                        
                              /dev/sda2(0)
  LogVol01                  VolGroup00    -wi-ao  1.94G                        
                              /dev/sda2(2318)
  resync_nosync             mirror_sanity mwi-a-  2.00G                   
resync_nosync_mlog  100.00        
resync_nosync_mimage_0(0),resync_nosync_mimage_1(0)
  [resync_nosync_mimage_0]  mirror_sanity iwi-ao  2.00G                        
                              /dev/sdd1(0)
  [resync_nosync_mimage_1]  mirror_sanity iwi-ao  2.00G                        
                              /dev/sdb5(0)
  [resync_nosync_mlog]      mirror_sanity lwi-ao  4.00M                        
                              /dev/sdb3(0)
  resync_regular            mirror_sanity mwi-a-  2.00G                   
resync_regular_mlog  10.55        
resync_regular_mimage_0(0),resync_regular_mimage_1(0)
  [resync_regular_mimage_0] mirror_sanity Iwi-ao  2.00G                        
                              /dev/sdd1(512)
  [resync_regular_mimage_1] mirror_sanity Iwi-ao  2.00G                        
                              /dev/sdb2(0)
  [resync_regular_mlog]     mirror_sanity lwi-ao  4.00M                        
                              /dev/sdb5(512)


Version-Release number of selected component (if applicable):
lvm2-2.02.32-1.el5
lvm2-cluster-2.02.32-1.el5

How reproducible:
everytime
Comment 1 Dave Wysochanski 2008-02-11 01:14:48 EST
Could probably fix this easily by adding a "count_visible_lv()" function which
iterates over lvs and calls "lv_is_visible()".  Should also examine the code for
other instances of this incorrect LV counting.
Comment 2 Peter Rajnoha 2008-11-26 04:53:38 EST
In case we have, for example, one snapshot volume in VG, lv_is_visible() will take into account all 3 LVs in this case and mark them as visible. I think that could confuse the user because only 2 LVs are visible actually (origin+snapshot). I would probably do this by checking the VISIBLE_LV flag directly and not calling lv_is_visible().
Comment 3 Peter Rajnoha 2008-12-04 04:17:43 EST
*** Bug 465168 has been marked as a duplicate of this bug. ***
Comment 4 Peter Rajnoha 2008-12-04 11:46:33 EST
There are other places in code where similar inconsistency related to counting visible LVs (from user's perspective!) can be found, like in output of "vgdisplay -c" command. Snapshot volumes should be counted in statistics of open LVs within the output of "vgdisplay", "vgremove" should count snapshot volumes as well while displaying the message about the number of LVs beeing deleted. Renaming of hidden snapshot volumes should not be allowed for a user.

All these cases are related to testing the visibility and counting of LVs from user's perpsective, so two new functions have been proposed - displayable_lvs_in_vg counting LVs in a given VG that are displayable to the user through outputs of commands and lv_is_displayable testing the actual visibility of an LV. These should be used instead of lv_is_visible function whenever a test for visibility and counting from user's perspective is needed (e.g. in listings and outputs of user commands).

The fix has been uploaded to CVS.
Comment 6 Milan Broz 2009-05-21 05:22:01 EDT
Fix in version lvm2-2.02.46-1.el5.
Comment 8 Corey Marthaler 2009-05-26 15:26:49 EDT
Fix verified in lvm2-2.02.46-2.el5.
Comment 10 errata-xmlrpc 2009-09-02 07:57:35 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1393.html

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