Bug 688394 - RFE: use the previous log device when allocating a new leg after device failure
Summary: RFE: use the previous log device when allocating a new leg after device failure
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.1
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Jonathan Earl Brassow
QA Contact: Corey Marthaler
URL:
Whiteboard:
Depends On:
Blocks: 756082
TreeView+ depends on / blocked
 
Reported: 2011-03-16 22:59 UTC by Corey Marthaler
Modified: 2012-01-04 21:45 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-04 21:45:18 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Corey Marthaler 2011-03-16 22:59:28 UTC
Description of problem:
When a 2-way mirror suffers a leg device failure and it's policy is set to allocate, that mirror is down converted to linear and then up converted back to a 2-way mirror again. During this process, the original log device is removed and replaced even though it didn't fail. LVM should attempt to use that same device if it can since there's a chance the user specified that device specifically during creation.

# Fail the SECONDARY device

# before the failure
[root@taft-01 ~]# lvs -a -o +devices
 LV                                 Log                          Devices
 syncd_secondary_2legs_1            syncd_secondary_2legs_1_mlog syncd_secondary_2legs_1_mimage_0(0),syncd_secondary_2legs_1_mimage_1(0)
 [syncd_secondary_2legs_1_mimage_0]                              /dev/sdc1(0)
 [syncd_secondary_2legs_1_mimage_1]                              /dev/sdf1(0)
 [syncd_secondary_2legs_1_mlog]                                  /dev/sdg1(0)

# after the failure
[root@taft-01 ~]# lvs -a -o +devices
 LV                                 Log                          Devices
 syncd_secondary_2legs_1            syncd_secondary_2legs_1_mlog syncd_secondary_2legs_1_mimage_0(0),syncd_secondary_2legs_1_mimage_1(0)
 [syncd_secondary_2legs_1_mimage_0]                              /dev/sdc1(0)
 [syncd_secondary_2legs_1_mimage_1]                              /dev/sdh1(0)
 [syncd_secondary_2legs_1_mlog]                                  /dev/sdb1(0)


# Fail the PRIMARY device
 
# before the failure
[root@taft-01 ~]# lvs -a -o +devices
 LV                               Log                        Devices
 syncd_primary_2legs_1            syncd_primary_2legs_1_mlog syncd_primary_2legs_1_mimage_0(0),syncd_primary_2legs_1_mimage_1(0)
 [syncd_primary_2legs_1_mimage_0]                            /dev/sdf1(0)
 [syncd_primary_2legs_1_mimage_1]                            /dev/sdh1(0)
 [syncd_primary_2legs_1_mlog]                                /dev/sde1(0)

# after the failure
[root@taft-01 ~]# lvs -a -o +devices
 LV                               Log                        Devices
 syncd_primary_2legs_1            syncd_primary_2legs_1_mlog syncd_primary_2legs_1_mimage_0(0),syncd_primary_2legs_1_mimage_1(0)
 [syncd_primary_2legs_1_mimage_0]                            /dev/sdh1(0)
 [syncd_primary_2legs_1_mimage_1]                            /dev/sdg1(0)
 [syncd_primary_2legs_1_mlog]                                /dev/sdb1(0)



Version-Release number of selected component (if applicable):
2.6.32-94.el6.x86_64

lvm2-2.02.83-2.el6    BUILT: Tue Feb  8 10:10:57 CST 2011
lvm2-libs-2.02.83-2.el6    BUILT: Tue Feb  8 10:10:57 CST 2011
lvm2-cluster-2.02.83-2.el6    BUILT: Tue Feb  8 10:10:57 CST 2011
udev-147-2.31.el6    BUILT: Wed Jan 26 05:39:15 CST 2011
device-mapper-1.02.62-2.el6    BUILT: Tue Feb  8 10:10:57 CST 2011
device-mapper-libs-1.02.62-2.el6    BUILT: Tue Feb  8 10:10:57 CST 2011
device-mapper-event-1.02.62-2.el6    BUILT: Tue Feb  8 10:10:57 CST 2011
device-mapper-event-libs-1.02.62-2.el6    BUILT: Tue Feb  8 10:10:57 CST 2011
cmirror-2.02.83-2.el6    BUILT: Tue Feb  8 10:10:57 CST 2011

Comment 1 Sayan Saha 2011-05-24 20:14:42 UTC
No capacity in 6.2. Re-evaluate for RHEL 6.3

Comment 3 Alasdair Kergon 2012-01-04 21:15:03 UTC
Might be doable, I'm not sure.  Jon, please see if the code can easily support this, or if the two steps are completely independent.  (Effectively the log needs splitting off into a separate LV instead of deleting, and then the 2nd step needs to accept that pre-existing log as an LV instead of allocating a new one.  Could be a cmdline extension like the 'make me a snapshot using this pre-existing cow' one.)

Comment 4 Jonathan Earl Brassow 2012-01-04 21:34:32 UTC
Focus will be on "raid1" segment type for the future.  Although a nice-to-have feature, the current solution harms no-one and we should be encouraging use of "raid1" not making it easier to stay on a legacy segment type.

Comment 5 RHEL Program Management 2012-01-04 21:45:18 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.


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