+++ This bug was initially created as a clone of Bug #500002 +++

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.

--- Additional comment from riel on 2009-05-09 20:50:15 EDT ---

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...

--- Additional comment from agk on 2009-05-10 20:53:53 EDT ---

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.)

--- Additional comment from mbroz on 2009-05-11 06:54:46 EDT ---

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...)

--- Additional comment from riel on 2009-05-11 10:20:52 EDT ---

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)