Bug 199749
Summary: | mirror leg failure during syncing will cause corrupt volume | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Corey Marthaler <cmarthal> |
Component: | lvm2 | Assignee: | Jonathan Earl Brassow <jbrassow> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.0 | CC: | agk, dwysocha, jbrassow, mbroz |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-01-26 19:06:54 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Corey Marthaler
2006-07-21 18:26:14 UTC
'dmsetup status' ? Which device did you disable? The primary, or other? It's been awhile since trying that but I have to believe that both cases were attempted (primary and other) due to the large number of times that I attempted that test case. I try and reproduce this again and get more info for you... Back to mirror leg failure testing once again... I tried this today but had different results. Not quite as bad as in this original report, but still an issue. After the primary leg failure, I was still able to access the filesystem and the data on the mirror. The mirror then appear to be automatically down convert to a linear. All appear to be fine until I powered up the now failed leg. Once it was back up, lvm started reporting the mirror as inconsistent. I then attempt to upconvert the linear back to the way the mirror was orginally and that failed. # Powered up the mirror and then... [root@link-08 ~]# lvscan Volume group "vg" inconsistent Inconsistent metadata copies found - updating to use version 7 ACTIVE '/dev/vg/mirror' [752.00 MB] inherit [root@link-08 ~]# pvscan Warning: Volume Group vg is not consistent PV /dev/sda1 VG vg lvm2 [135.66 GB / 134.92 GB free] PV /dev/sdb1 VG vg lvm2 [135.66 GB / 135.66 GB free] PV /dev/sdc1 VG vg lvm2 [135.66 GB / 135.66 GB free] PV /dev/sdd1 VG vg lvm2 [135.66 GB / 135.66 GB free] PV /dev/sde1 VG vg lvm2 [135.66 GB / 135.66 GB free] PV /dev/sdf1 VG vg lvm2 [135.66 GB / 135.66 GB free] PV /dev/sdg1 VG vg lvm2 [135.66 GB / 135.66 GB free] Total: 7 [949.59 GB] / in use: 7 [949.59 GB] / in no VG: 0 [0 ] [root@link-08 ~]# vgscan Reading all physical volumes. This may take a while... Volume group "vg" inconsistent Inconsistent metadata copies found - updating to use version 8 Found volume group "vg" using metadata type lvm2 [root@link-08 ~]# lvs -a -o +devices Volume group "vg" inconsistent Inconsistent metadata copies found - updating to use version 10 LV VG Attr LSize Origin Snap% Move Log Copy% Devices mirror vg -wi-ao 752.00M /dev/sda1(0) [root@link-08 ~]# lvconvert -m 0 /dev/vg/mirror Inconsistent metadata copies found - updating to use version 11 Logical volume mirror is already not mirrored. [root@link-08 ~]# lvconvert -m 1 /dev/vg/mirror Inconsistent metadata copies found - updating to use version 12 Volume group vg metadata is inconsistent Volume group for uuid not found: KgTtQPpOsnujX3DSDtRDiYZ97saUuNAAnrJPJNfix9cSfeBr76wwsWbTArWWnswa Aborting. Failed to activate mirror log. Remove new LVs and retry. Failed to create mirror log. [root@link-08 ~]# lvscan Volume group "vg" inconsistent Inconsistent metadata copies found - updating to use version 14 ACTIVE '/dev/vg/mirror' [752.00 MB] inherit inactive '/dev/vg/mirror_mlog' [4.00 MB] inherit # Note the appearance of the new mirror_mlog [root@link-08 ~]# dmsetup ls vg-mirror (253, 5) VolGroup00-LogVol01 (253, 1) VolGroup00-LogVol00 (253, 0) [root@link-08 ~]# dmsetup table vg-mirror: 0 1540096 linear 8:1 384 VolGroup00-LogVol01: 0 4063232 linear 3:2 151912832 VolGroup00-LogVol00: 0 151912448 linear 3:2 384 [root@link-08 ~]# dmsetup ls --tree vg-mirror (253:5) └─ (8:1) VolGroup00-LogVol01 (253:1) └─ (3:2) VolGroup00-LogVol00 (253:0) └─ (3:2) When you bring back the failed device, two VG's with the same name are now present. An inconsistent VG named "vg" and a consistent VG named "vg". They are conflicting in the namespace. The fix is to pvcreate/vgextend on the device you just brought back to life. The workaround mentioned in comment #5 has been verified to work. Marking verified. |