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
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 ***