Bug 537926 - 2 leg down convert request with only one PV specified probably should not work
Summary: 2 leg down convert request with only one PV specified probably should not work
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: lvm2
Version: 5.4
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Jonathan Earl Brassow
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks: 1049888
TreeView+ depends on / blocked
 
Reported: 2009-11-16 20:28 UTC by Corey Marthaler
Modified: 2014-02-04 15:03 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-30 00:10:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Corey Marthaler 2009-11-16 20:28:06 UTC
Description of problem:
This issue was brought up by Jon in this mornings LVM meeting...

If you have a VG with plenty of PVs in it, and you attempt to convert your 2-way mirror to 4-way, but only specify 1 PV to use, that attempt fails due to the lack of space, even though LVM could technically just pick another PV to use from the available list in the VG.

[root@hayes-01 ~]# lvconvert -m3 VG/mirror /dev/etherd/e1.1p13
  Not enough PVs with free space available for parallel allocation.
  Consider --alloc anywhere if desperate.
  Unable to allocate extents for mirror(s).

However, if the opposite is tried, you attempt to convert your 4-way mirror to a 2-way mirror, but only specify 1 PV to use, that attempt succeeds with LVM arbitrarily picking the other PV to remove.

[root@hayes-01 ~]# lvconvert -m1 VG/mirror /dev/etherd/e1.1p13
  Logical volume mirror converted.

This appears inconsistent, both attempts should either fail or succeed.


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

lvm2-2.02.54-1.el5    BUILT: Thu Nov 12 05:28:35 CST 2009
lvm2-cluster-2.02.54-1.el5    BUILT: Thu Nov 12 05:27:29 CST 2009
device-mapper-1.02.39-1.el5    BUILT: Wed Nov 11 12:31:44 CST 2009
cmirror-1.1.39-2.el5    BUILT: Mon Jul 27 15:39:05 CDT 2009
kmod-cmirror-0.1.22-1.el5    BUILT: Mon Jul 27 15:28:46 CDT 2009

How reproducible:
Everytime

Comment 1 Petr Rockai 2009-11-18 12:23:29 UTC
Well, my understanding of this is that for extension, the PVs given mean a set of what the system may choose from to allocate as it wishes (but not any more), whereas upon shrinking, it is the list of PVs you want to free up (freeing up extra is fine). However, I don't have a strong opinion about this.

Comment 3 Jonathan Earl Brassow 2010-01-26 21:30:55 UTC
Yes, the behavior is suspect...  I'm sure it will involve a discussion about historical behavior.  Petr shows the other side.

Perhaps we don't even need this bug.

I'll leave it for now.

Comment 4 Jonathan Earl Brassow 2014-01-30 00:10:48 UTC
Closing this bug WONTFIX.

I don't intend to change the behaviour of the way lvconvert works on mirrors at this stage.  However, it should be noted that 'raid1' type mirrors in RHEL6+ do behave in the way suggested in the original description, while 'mirror's still behave in the (subjectively) abnormal/inconsistent way.


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