lvm2:  Volume groups like /dev/vg0/amdata (backed by /dev/md1).
       For use ON TOP OF software raid

Edit /etc/lvm/lvm.conf and set "format" to "lvm2" so don't need to give
"-M2" switch to pvcreate (and probably other) commands.

When sizing partitions, allocate extra size to each VG containing LVs
which you want to take snapshot backups of.  Extra size needed is <= 20%
of the largest LV that you will back up.

[ For Linux RAID + LVM, do a straight RAID1 ext2 partition for /boot, and
  a straight LVM partition for swap ]

http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/LVM-HOWTO.html

Normal installation will not LVM /boot (but will /).  I.e., make a PV
 for /dev/X1 for every HDD except make /boot of boot disks plain ext2 or RAID.
(Suse installer won't even let you mount an LV onto /boot).
Root on LVM requires an initrd image that activates the root LVM (np for
newer kernels).
Can LVM swap partitions.  Useful so you can move space to/from fs partitions
 without needing to run fdisk (and taking the filesystems offline).
Use partition type 8e (LVM) (necessary only for LVM v. 1?)

LVM
    It's very easy to move all the physical disks of a VG from one system
    to another.

    I think that the concerns about LV of / are obsolete, since they
    disregard their own warnings in the HOWTO examples.

    PV: Old fashioned disk partition like /dev/hda1 or /dev/md1.
        (Allocated in PE blocks/chunks)
        General recommendation is to make one entire-disk partition for each
        hard disk, and make one PV for each of these.
    VG: Group of PVs.
    LV: Slice of a VG which can be formatted and mounted.
        (Allocated in LE blocks/chunks)
    Extents:  Block/chunk size of PV = block/chunk size of LV.

    LV mapping.  I guess you specify for each LV how PV blocks are allocated
    (generally concatenations of stripes).

    pvcreate /dev/hdb /dev/hdc1   # Initialize an entire disk + a partition
        (Should not use whole-disk devices like /dev/hdb, but if do,
        need to zero out part. table first.  See docs).
        Extra step for partition on disk containing DOS partition(s)).
        (Assumes "format lvm2" set in lvm.conf).
    vgcreate vgMine /dev/hdb /dev/hdc1  # Can give non-dflt extent size
        (I think this activates the VG too).
    vgchange -a y vgMine  # Need to activate after reboot
    lvcreate -L1600 -nlvName vgMine [pv1 pv2...]  # Linear.
             # -L size in M by default, but can use G or T.
             # Can also supply size in -l extents, num stripes, stripe size.

    Maint commands:
    pvresize  seems to serve similar function to vgextend (obviously for pvs)
    vgextend vgMine /dev/hdd1
    vgchange -an vgMine
    vgremove vgMine   # Remember this removes the vg, not any pv.
    pvscan
    pvdisplay [/dev/hdc1]
    lvdisplay [/dev/hdc1]
    pvmove [-v] /dev/pvname [/dev/other]
                      # Moves all extents to other PVs of the VG.
    lvscan
    vgreduce vgMine /dev/hdc1   # Opposite of vgextend. 
    lvremove /dev/vgMine/lvName
    lvextend -L12G lv   # [IN M]   OR      lvextend -L+1
    lvextend -l+22 lv   # [IN EXTENTS] Specify additional EXTENTS (this better
                        for extending to max size reported by "vgdisplay").
    lvextend -l 30%KW        # Where KeyWord is one of a few things
      # L Units default to MB.  No + means absolute.  Can also specify %.
      (Looks like no diff between capital and lower units, like "g" vs. "G").
    resize2fs /dev/vgMine/lvName   # for ext2/ext3/ext4
    resize_reiserfs /dev/vgMine/lvName   # for...
    REDUCING lvs:
        umount /mount/pooint
        resize2fs/resize_reiserfs -s -1G /dev/vgMine/lvName
        lvreduce -L-1G /dev/vgMine/lvName
    REMOVING pv's.  Guide says to "vgreduce vgMine /dev/pvname", but why not
     use "pvremove" command?

RUN vgcfgbackup to back up LVM metadata.

Make snapshot partition for taking a backup
    lvcreate -L592M -s -nlvSnap /dev/vgMine/lvSrc
             # Create snapshot volume of lvSrc.  Populates the snapshot.
             # Size it TO BE SURE IT CAN HOLD ALL DATA ***CHANGES***
    lvremove -f /dev/vgMine/lvSnap    # ALWAYS remove when done w/ snapshot
There is some quirkiness to when/how snap volumes show up in lvdisplay.
Sometimes the LV Name shows up, but sometimes it just shows up under
"LV snapshot status" of the source LV.

From configuration in /etc/sysconfig/lvm, lvm makes automatic backups of
same exact format as from vgcfgbackup, in
    /etc/lvm/backup   capture from before LAST vgscan run
    /etc/lvm/archive   versioned captures persisted after vgscan run
                       (purged according to sysconfig settings).

RECOVERY
If RAID-protected, then just recover using mdadm.
If unprotected, then remove the pvs with
    vgreduce vgname --removemissing

SNAP LOCKING DIAGNOSTICS
dmsetup info -c
"vgscan", then look at /etc/lvm/.cache to see which devices are used.