Bug 500002 - lvm manpages dangerously sparse
lvm manpages dangerously sparse
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: lvm2 (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Milan Broz
Cluster QE
:
Depends On:
Blocks: 500177
  Show dependency treegraph
 
Reported: 2009-05-09 20:09 EDT by Rik van Riel
Modified: 2013-02-28 23:07 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 500177 (view as bug list)
Environment:
Last Closed: 2011-08-11 10:06:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rik van Riel 2009-05-09 20:09:43 EDT
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.
Comment 1 Rik van Riel 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...
Comment 2 Alasdair Kergon 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.)
Comment 3 Milan Broz 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...)
Comment 4 Rik van Riel 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)
Comment 5 Corey Marthaler 2009-05-11 17:21:32 EDT
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)
Comment 6 Rik van Riel 2009-05-11 18:38:26 EDT
Originally /dev/lv0/root was on /dev/sdd2
Comment 7 Corey Marthaler 2009-05-12 15:10:34 EDT
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.
Comment 8 Corey Marthaler 2009-05-12 15:16:52 EDT
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.
Comment 11 Milan Broz 2011-08-11 10:06:34 EDT
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.)
Comment 12 Corey Marthaler 2011-08-17 18:11:40 EDT
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.
Comment 13 Corey Marthaler 2011-08-17 18:21:11 EDT
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."

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