Bug 483583 - RFE: allow the ability to stack pvs on top of existing origins (with snaps)
Summary: RFE: allow the ability to stack pvs on top of existing origins (with snaps)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: lvm2
Version: 5.3
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: LVM and device-mapper development team
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-02 15:13 UTC by Corey Marthaler
Modified: 2010-11-01 11:32 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-01 03:39:34 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Corey Marthaler 2009-02-02 15:13:10 UTC
Description of problem:
This is likely the same issue as bug 481384.

[root@hayes-03 cache]# lvs -a -o +devices
  LV       VG         Attr   LSize   Origin  Snap%  Move Log Copy%  Convert Devices               
  origin1  base1      owi-a- 100.00M                                        /dev/etherd/e1.1p1(0) 
  snap1    base1      swi-a-  12.00M origin1   0.13                         /dev/etherd/e1.1p1(25)
  origin2  base2      owi-a- 100.00M                                        /dev/etherd/e1.1p2(0) 
  snap2    base2      swi-a-  12.00M origin2   0.13                         /dev/etherd/e1.1p2(25)


[root@hayes-03 cache]# pvcreate /dev/base1/origin1 
  Physical volume "/dev/base1/origin1" successfully created
[root@hayes-03 cache]# pvcreate /dev/base2/origin2
  Physical volume "/dev/base2/origin2" successfully created

[root@hayes-03 cache]# pvscan
  Found duplicate PV F4qW107N5AhBuGaVkFRgLFYCbjhEf7Ms: using /dev/mapper/base1-origin1-real not /dev/base1/origin1
  Found duplicate PV rh9vKtdPUAcItGPnmI7OyNdopfI2WSpi: using /dev/mapper/base2-origin2-real not /dev/base2/origin2
  PV /dev/etherd/e1.1p2               VG base2           lvm2 [1.77 TB / 1.77 TB free]
  PV /dev/etherd/e1.1p1               VG base1           lvm2 [1.77 TB / 1.77 TB free]
  PV /dev/sda2                        VG VolGroup00      lvm2 [74.38 GB / 0    free]
  PV /dev/mapper/base1-origin1-real                      lvm2 [100.00 MB]
  PV /dev/mapper/base2-origin2-real                      lvm2 [100.00 MB]
  PV /dev/etherd/e1.1p3                                  lvm2 [1.77 TB]
  PV /dev/etherd/e1.1p4                                  lvm2 [1.77 TB]
  PV /dev/etherd/e1.1p5                                  lvm2 [1.77 TB]
  Total: 8 [8.94 TB] / in use: 3 [3.62 TB] / in no VG: 5 [5.32 TB]

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

lvm2-2.02.40-6.el5    BUILT: Fri Oct 24 07:37:33 CDT 2008
lvm2-cluster-2.02.40-7.el5    BUILT: Wed Nov 26 07:19:19 CST 2008
device-mapper-1.02.28-2.el5    BUILT: Fri Sep 19 02:50:32 CDT 2008


How reproducible:
Everytime

Comment 1 Jonathan Earl Brassow 2009-03-11 17:01:04 UTC
Removing 5.4 flag.

Stacking comes in two flavors:
1) The ability to stack LVs in the same vg, like creating a RAID10, etc
2) Creating new VGs on top of existing LVs in another VG.

#1 is a significant portion of work that has been talked about for a long time, but probably won't be seen in RHEL5.

#2 is possible in rudimentary forms.  When more exotic stacking takes place - like putting a VG on top of a mirror or snapshot - the concept starts to break down.  It is possible to run around and stomp out all the bugs associated with this in the RHEL5 timeframe, but I don't think anyone can be tasked to it in 5.4.

Comment 3 Mikuláš Patočka 2010-11-01 03:39:34 UTC
Filter the snapshots in lvm.conf and it will work. Not a bug, but an incorrect configuration.

Comment 4 Alasdair Kergon 2010-11-01 11:11:25 UTC
If stacking on top of an origin+snapshot, the snapshot *must* be writeable and the PV uuid within it changed OR filters must be used to ignore one of the two devices.  It is impossible for any general rule to guess the right default without some level of manual intervention.

Comment 5 Mikuláš Patočka 2010-11-01 11:32:04 UTC
Maybe we could change the error message to suggest to the user that he should edit "filter" clause in lvm.conf --- because this problem is repeated several times in our bugzilla.


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