這個實驗來自於紅皮書，通過這個實驗可以很好的瞭解redefinevg和synclvodm的區別。

redefinevg和synclvodm命令

最常見的ODM問題是:ODM和LVM控制資訊不同步。這種情況下，一般是ODM中的資訊不準確(但不一定所有的問題都是如此)，而磁碟上的VGDA和VGSA是準確的。
修復ODM資訊不準確的問題最常用的兩個命令:redefinevg、synclvodm。redefinevg將重建ODM中的VG和PV資訊，給出足夠的資訊去啟用卷組，它也會恢復一些LV的資訊；synclvodm將從VGDA和LVCB中恢復剩下的LV資訊，以提供對LV的訪問。

通過下面的例子，我們能很好的理解redefinevg和synclvodm這兩個命令的區別。在下面的例子中，我們將建立名為targetvg的卷組，並在targetvg上建立targetlv檔案系統，log lv為targetlog，mount點為/targetfs。

# lsvg -l targetvg
targetvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
targetlog           jfslog     1       1       1    closed/syncd  N/A
targetlv            jfs        32      32      1    closed/syncd  /targetfs
# mount /targetfs
# echo "data" > /targetfs/data

我們假設這個VG裡面的需要的所有ODM資訊都損壞了，我們用odmdelete來達到破壞ODM資訊的效果，在刪除之前首先是備份資訊(odmget備份)。
# odmdelete -o CuAt -q "name LIKE target*"
0518-307 odmdelete: 9 objects deleted.
# odmdelete -o CuDvDr -q "value3 LIKE target*"
0518-307 odmdelete: 3 objects deleted.
# odmdelete -o CuDvDr -q "value1=targetvg"
0518-307 odmdelete: 1 objects deleted.
# odmdelete -o CuDv -q "name LIKE target*"
0518-307 odmdelete: 3 objects deleted.
# odmdelete -o CuDep -q "name=targetvg"
0518-307 odmdelete: 2 objects deleted.

現在讓我們來看看下面的結果。
# lsvg
rootvg
# lsvg -o
0516-304 : Unable to find device id 005f3e8e00004c000000013ac3744be1 in the Device
        Configuration Database.
vgid=005f3e8e00004c000000013ac3744be1
rootvg
# lspv -M hdisk1
0516-320 : Physical volume hdisk1 is not assigned to
        a volume group.
# lslv -m targetlv
0516-306 lslv: Unable to find  targetlv in the Device
        Configuration Database.

在ODM資訊被破壞之後，我們查詢不到關於VG的資訊，依賴於vg的lv資訊也查詢不到。
即使ODM中資訊是混亂的，資料依然可用，我們仍可以進行mount和umount
一些人可能會用exportvg或varyonvg來修復這個問題，我們可以儘管一試

# exportvg targetvg
0516-306 getlvodm: Unable to find volume group targetvg in the Device
        Configuration Database.
0516-772 exportvg: Unable to export volume group targetvg
# varyonvg targetvg
0516-008 varyonvg: LVM system call returned an unknown
        error code (3).
為什麼exportvg沒有成功呢？因為exportvg的前提是vg的定義還在，但是我們已經刪除了在odm中的vg定義，
vg的定義不在，所以執行失敗。

推薦的修復操作：synclvodm targetvg，也將會失敗，同樣是因為在odm中vg的定義已不在。
# synclvodm targetvg
0516-306 : Unable to find volume group targetvg in the Device
        Configuration Database.
0516-502 synclvodm: Unable to access volume group targetvg.

為了恢復基礎的ODM資訊，我們必須使用redefinevg，這裡我們用redefinevg -d hdisk1 targetvg來恢復
在恢復之前，我們可以先用lqueryvg -Atp hdisk1來確認vgid資訊。
# lqueryvg -Atp hdisk1
0516-320 lqueryvg: Physical volume hdisk1 is not assigned to
        a volume group.
Max LVs:        256
PP Size:        28
Free PPs:       1059
LV count:       2
PV count:       2
Total VGDAs:    3
Conc Allowed:   0
MAX PPs per PV  1016
MAX PVs:        32
Quorum (disk):  1
Quorum (dd):    1
Auto Varyon ?:  1
Conc Autovaryo  0
Varied on Conc  0
Logical:        005f3e8e00004c000000013ac3744be1.1   targetlog 1  
                005f3e8e00004c000000013ac3744be1.2   targetlv 1  
Physical:       00cb6010395938b0                2   0  
                0007c06c50569818                1   0  
Total PPs:      1092
LTG size:       128
HOT SPARE:      0
AUTO SYNC:      0
VG PERMISSION:  0
SNAPSHOT VG:    0
IS_PRIMARY VG:  0
PSNFSTPP:       4352
VARYON MODE:    ???????
VG Type:        0
Max PPs:        32512

我們可以看到，005f3e8e00004c000000013ac3744be1正好是我們用lsvg -o查出的丟失的vgid
我們執行redefinevg命令
# redefinevg -d hdisk1 targetvg
#

執行成功之後，檢查資訊
# lsvg
rootvg
targetvg
# lsvg -o
targetvg
rootvg
# lsvg -l targetvg
targetvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
targetlog           ???        1       1       1    open/syncd    N/A
targetlv            ???        32      32      1    open/syncd    /targetfs
#

到此為止，我們還沒有完全修復好ODM中的targetvg資訊，還需要檢查下當前ODM庫中的資訊。
# odmget CuAt |grep -ip targetvg
CuAt:
        name = "targetvg"
        attribute = "vgserial_id"
        value = "005f3e8e00004c000000013ac3744be1"
        type = "R"
        generic = "D"
        rep = "n"
        nls_index = 637

CuAt:
        name = "targetvg"
        attribute = "pv"
        value = "00cb6010395938b00000000000000000"
        type = "R"
        generic = ""
        rep = "sl"
        nls_index = 0

CuAt:
        name = "targetvg"
        attribute = "pv"
        value = "0007c06c505698180000000000000000"
        type = "R"
        generic = ""
        rep = "sl"
        nls_index = 0

# odmget CuDv |grep -ip targetvg
CuDv:
        name = "targetvg"
        status = 1
        chgstatus = 1
        ddins = ""
        location = ""
        parent = ""
        connwhere = ""
        PdDvLn = "logical_volume/vgsubclass/vgtype"

# odmget CuDvDr |grep -ip targetvg
CuDvDr:
        resource = "ddins"
        value1 = "targetvg"
        value2 = "42"
        value3 = ""

CuDvDr:
        resource = "devno"
        value1 = "42"
        value2 = "0"
        value3 = "targetvg"

# odmget CuDep |grep -ip targetvg

由上面的資訊可以看出（也可以跟我們之前備份的資訊對比），我們已經重建了odm庫中targetvg的vgid，pv資訊，但是我們還沒有從lvcb中
恢復lv資訊，這就是為什麼我們在lsvg -l targetvg結果的type列中，顯示為“？”的原因。在這個階段，像extendlv等命令將執行失敗，因為在
odm中沒有關於targetvg的lv資訊。
# extendlv targetlv 1
0516-306 getlvodm: Unable to find  targetlv in the Device
        Configuration Database.
0516-788 extendlv: Unable to extend logical volume.
#

要修復這個問題，執行synclvodm命令，這樣，lvcb控制資訊將會恢復到ODM中，做完這一步後，所有的ODM資訊都被恢復了。
# synclvodm targetvg
# lsvg -l targetvg
targetvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
targetlog           jfslog     1       1       1    open/syncd    N/A
targetlv            jfs        32      32      1    open/syncd    /targetfs
#  savebase


總結：借用農哥的原話。
synclvodm是從VGDA同步ODM，前提是VG的定義還在，ODM裡錯誤的被修正，缺失的會從VGDA匯入，但ODM裡多的還會存在。
redefinevg也是從VGDA同步ODM，前提是VG定義沒了才用，要指定從哪個PV匯入，ODM裡多的還會在
synclvodm同步vgda和lvcb中的資訊到odm
redefinevg總是能執行成功的，因為pv資訊如果在odm中被刪除了，還可以通過cfgmgr來認出來
exportvg是把VGDA資訊從ODM庫中匯出去，前提也是VG的定義還在。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/196700/viewspace-1223795/，如需轉載，請註明出處，否則將追究法律責任。