Description of problem: The LVM man pages give just enough info to make a sysadmin feel like he knows what he's doing, without actually explaining enough for people to get LVM work done. In particular, the meaning of the [PhysicalVolume[Path]...] arguments can vary from command to command and is not explained in any of the LVM man pages. As an example, when lvconverting a linear logical volume into a mirrored logical volume, with the mirror on a specific disk, one needs to specify *two* physical volume paths. One is for the mirror volume and the other is for the mirror log. This is not explained in the man page, nor is there any explanation which is which. Other commands are similarly sparsely documented. Feel free to move this bug to RHEL 6, but please document the LVM tools well enough that the man pages are no longer a danger to sysadmins.
lvconvert -m 0 is similarly dangerous. Once I saw that lvconvert -m 1 was copying data to the wrong disk, I issued an lvconvert -m 0 command, specifying the physical volume I wanted the volume to stay on. Of course, lvconvert interpreted the physical volume argument as the physical volume to *delete*, causing the remaining linear volume to point at an incomplete copy of my root filesystem! I'm restoring from backup now and not too happy about it. I can only imagine how unhappy our paying customers must be...
What have the man pages got to do with this? If lvconvert -m1 followed by lvconvert -m0 led to corruption then that's a serious software bug! It obviously makes no sense for the tools to allow you drop an out-of-sync mimage from a mirror without waiting for it to get synced first - if that's what they actually did. (Mirrors of root filesystems are not supported yet, by the way, as initrd and anaconda support are missing.)
In IRC chat you mentioned "lvresize mistake" too. Are you sure that the problem is with lvconvert? lvconvert must not corrupt data, if this happens, it is serious bug. Even when you specify wrong PV arguments. (And these arguments are optional, because allocation policy (man lvm --alloc) selects the PV for mirror images automatically. But optional PV args should be documented properly, though...)
Yes, the problem is with lvconvert. I have not run lvresize recently. The commands that caused me trouble: lvconvert -m 1 --mirrorlog /dev/vg0/root /dev/sda2 (refuses to do anything, because I specified only one PV - needs manpage fix) lvconvert -m 1 --mirrorlog /dev/vg0/root /dev/sda2 /dev/sdb2 (hey, why are you moving all my data onto sdb2? I wanted sda2 - needs manpage fix) After interrupting the lvconvert -m 1: lvconvert -m 0 /dev/vg0/root /dev/sdd2 (aaaargh, why did you *remove* sdd2 from the mirror set?! that was the complete copy of my root filesystem, now I'm left without the root fs)
What device was /dev/vg0/root on to begin with? I attempted this with a linear volume on /dev/sdb1 and upconverted it to a mirror and the device the linear was originally on, stayed the primary leg. [root@grant-01 ~]# lvs -a -o +devices LV VG Attr LSize Origin Snap% Move Log Copy% Convert Devices LogVol00 VolGroup00 -wi-ao 64.56G /dev/sda2(0) LogVol01 VolGroup00 -wi-ao 9.81G /dev/sda2(2066) corey grant -wi-a- 1.00G /dev/sdb1(0) [root@grant-01 ~]# pvscan PV /dev/sdb1 VG grant lvm2 [90.82 GB / 89.82 GB free] PV /dev/sdb2 VG grant lvm2 [90.82 GB / 90.82 GB free] PV /dev/sdb3 VG grant lvm2 [90.82 GB / 90.82 GB free] PV /dev/sda2 VG VolGroup00 lvm2 [74.38 GB / 0 free] [root@grant-01 ~]# lvconvert -m 1 --mirrorlog disk /dev/grant/corey /dev/sdb2 /dev/sdb3 /dev/grant/corey: Converted: 25.4% /dev/grant/corey: Converted: 36.3% /dev/grant/corey: Converted: 45.7% /dev/grant/corey: Converted: 49.2% /dev/grant/corey: Converted: 64.5% /dev/grant/corey: Converted: 78.9% /dev/grant/corey: Converted: 91.8% /dev/grant/corey: Converted: 100.0% Logical volume corey converted. [root@grant-01 ~]# lvs -a -o +devices LV VG Attr LSize Origin Snap% Move Log Copy% Convert Devices LogVol00 VolGroup00 -wi-ao 64.56G /dev/sda2(0) LogVol01 VolGroup00 -wi-ao 9.81G /dev/sda2(2066) corey grant mwi-a- 1.00G corey_mlog 100.00 corey_mimage_0(0),corey_mimage_1(0) [corey_mimage_0] grant iwi-ao 1.00G /dev/sdb1(0) [corey_mimage_1] grant iwi-ao 1.00G /dev/sdb2(0) [corey_mlog] grant lwi-ao 4.00M /dev/sdb3(0)
Originally /dev/lv0/root was on /dev/sdd2
When down converting (-m 0) the phys vol given is the leg that gets removed, even if it's the current primary leg (I did not know that before today). This should be documented in the man page or the help output. [root@grant-01 ~]# lvs -a -o +devices grant corey grant mwi-a- 1.00G corey_mlog 100.00 corey_mimage_0(0),corey_mimage_1(0) [corey_mimage_0] grant iwi-ao 1.00G /dev/sdb2(0) [corey_mimage_1] grant iwi-ao 1.00G /dev/sdb1(0) [corey_mlog] grant lwi-ao 4.00M /dev/sdb3(0) [root@grant-01 ~]# lvconvert -m 0 grant/corey /dev/sdb2 Logical volume corey converted. [root@grant-01 ~]# lvs -a -o +devices grant LV VG Attr LSize Origin Snap% Move Log Copy% Convert Devices corey grant -wi-a- 1.00G /dev/sdb1(0) However what you posted about up converting (-m 1) does not appear to match what actually happens in lvm. [root@grant-01 ~]# lvconvert -m 1 --mirrorlog disk /dev/grant/corey /dev/sdb3 /dev/sdb2 /dev/grant/corey: Converted: 27.7% /dev/grant/corey: Converted: 67.2% /dev/grant/corey: Converted: 97.3% /dev/grant/corey: Converted: 100.0% Logical volume corey converted. corey grant mwi-a- 1.00G corey_mlog 100.00 corey_mimage_0(0),corey_mimage_1(0) [corey_mimage_0] grant iwi-ao 1.00G /dev/sdb1(0) [corey_mimage_1] grant iwi-ao 1.00G /dev/sdb3(0) [corey_mlog] grant lwi-ao 4.00M /dev/sdb2(0) The original linear device stayed the primary device each time that I tried this. So I'm not sure how you were able to lose the data on that device.
One other thing that should probably be added to the man pages, is that lvm, when given 2 disks for an up convert, appears to choose the smaller of the two for the log and the larger of the two for the secondary leg, regardless of the order that they are given on the cmdline.
I will close this one - while I understand the problem of lvconvert complexity, I am not sure what exactly is missing on man pages now. (Maybe Corey can open new bug with the exact description what is missing on man page - comment #8? Thanks.)
FWIW, I was not able to reproduce the behavior I mentioned in comment #8 with the latest rpms. All four attempts to upconvert a linear showed that the first device specified on the cmdline was used as the secondary device whether or not it was the largest device. That should also be the expected behavior.
Also, the lvconvert man page already describes the behavior I learned in comment #7, so I don't see any additional man page issues to be opened from this bug. "If the conversion frees physical extents (for example, when converting from a mirror to a linear, or reducing mirror legs) and you specify one or more PhysicalVolumes, the freed extents come first from the specified PhysicalVolumes."