Bug 507400 - RHEL5 cmirror tracker: reducing mirror size doesn't recalculate copy percent
RHEL5 cmirror tracker: reducing mirror size doesn't recalculate copy percent
Status: CLOSED DUPLICATE of bug 479749
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cmirror (Show other bugs)
5.4
All Linux
low Severity medium
: rc
: ---
Assigned To: Jonathan Earl Brassow
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-22 12:17 EDT by Corey Marthaler
Modified: 2010-01-11 21:10 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-21 11:14:54 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 2009-06-22 12:17:38 EDT
Description of problem:
This results in copy percents greater than 100%. I can't reproduce this with single machine mirrors, but can with cluster mirrors created with or without the --nosync option.


[root@taft-03 ~]# lvcreate -m 1 -n mirror -L 50M taft
  Rounding up size to full physical extent 52.00 MB
  Logical volume "mirror" created

[root@taft-03 ~]# lvs -a -o +devices
  LV                VG         Attr   LSize  Origin Snap%  Move Log         Copy%  Convert Devices                              
  LogVol00          VolGroup00 -wi-ao 58.38G                                               /dev/sda2(0)                         
  LogVol01          VolGroup00 -wi-ao  9.75G                                               /dev/sda2(1868)                      
  mirror            taft       mwi-a- 52.00M                    mirror_mlog 100.00         mirror_mimage_0(0),mirror_mimage_1(0)
  [mirror_mimage_0] taft       iwi-ao 52.00M                                               /dev/sdb1(0)                         
  [mirror_mimage_1] taft       iwi-ao 52.00M                                               /dev/sdc1(0)                         
  [mirror_mlog]     taft       lwi-ao  4.00M                                               /dev/sdh1(0)                         

[root@taft-03 ~]# lvreduce -L 35M taft/mirror
  Rounding up size to full physical extent 36.00 MB
  WARNING: Reducing active logical volume to 36.00 MB
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce mirror? [y/n]: y
  Reducing logical volume mirror to 36.00 MB
  Logical volume mirror successfully resized

[root@taft-03 ~]# lvs -a -o +devices
  LV                VG         Attr   LSize  Origin Snap%  Move Log         Copy%  Convert Devices                              
  LogVol00          VolGroup00 -wi-ao 58.38G                                               /dev/sda2(0)                         
  LogVol01          VolGroup00 -wi-ao  9.75G                                               /dev/sda2(1868)                      
  mirror            taft       mwi-a- 36.00M                    mirror_mlog 144.44         mirror_mimage_0(0),mirror_mimage_1(0)
  [mirror_mimage_0] taft       iwi-ao 36.00M                                               /dev/sdb1(0)                         
  [mirror_mimage_1] taft       iwi-ao 36.00M                                               /dev/sdc1(0)                         
  [mirror_mlog]     taft       lwi-ao  4.00M                                               /dev/sdh1(0)                         


Version-Release number of selected component (if applicable):
2.6.18-150.el5

lvm2-2.02.46-8.el5    BUILT: Thu Jun 18 08:06:12 CDT 2009
lvm2-cluster-2.02.46-8.el5    BUILT: Thu Jun 18 08:05:27 CDT 2009
device-mapper-1.02.32-1.el5    BUILT: Thu May 21 02:18:23 CDT 2009
cmirror-1.1.37-1.el5    BUILT: Tue May  5 11:46:05 CDT 2009
kmod-cmirror-0.1.21-14.el5    BUILT: Thu May 21 08:28:17 CDT 2009


How reproducible:
Everytime
Comment 1 Jonathan Earl Brassow 2009-07-21 11:14:54 EDT
This bug is the same as 479749.  The problem is that the same identifier (UUID) is used to describe the log in both cases.  Since there are two instances (references) of a log with the same name, there is no clean way to decide which log to throw away when switching.  In the case of this bug and 479749, the choice to throw away the new one and keep the old one is what is causing the bug.

*** This bug has been marked as a duplicate of bug 479749 ***

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