免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 2296 | 回复: 0

[新手入门] 乱七八糟的VG [复制链接]

论坛徽章:
0
发表于 2006-08-01 21:26 |显示全部楼层
暑假作业:乱七八糟的VG
前传:
有个lpar,3个vg,分别是rootvg, datavg和reloadvg(以前写avg,bvg总让人误会,呵呵)。datavg有6块盘,reloadvg有7块盘。我要加两块盘进datavg,cfgmgr后认出了新盘。于是,噩梦开始了:
extendvg datavg vpath10
extendvg datavg vpath14
(上面的命令不正确,但未至于得出下面的结果)
加完后发现这两块盘变成了属于reloadvg。留意了一下pvid,原来新盘的pvid跟reloadvg里面其中两块旧盘相同。
reducevg reloadvg vpath10
reducevg reloadvg vpath14
这下更惨了,新盘是脱离了reloadvg,但跟它们相同pvid的两块旧盘也被踢了出去。
我export reloadvg,但import不了。然后把那两个pvid改了后,重新extend 到datavg里面。我让同事过来帮忙,他用了importvg -f reloadvg vpath2。结果,出来一大堆error,然后lspv看,reloadvg的盘全没了。datavg的盘有5块变成reloadvg的,还有一块是datavg的。
然后,大家瞪大眼睛看着屏幕,镜头慢慢升高,两个男人痴痴地望着远处的群山。
背景音乐响起。。。。。。。。。。
一轮商议后,首先在800上,把新盘和所有reloadvg的盘拿走。其实系统表面上一切正常,所有服务都还在运行。我们首先对所有数据做了备份,然后export datavg。再在仅有的那块未被污染的盘上进行import,没问题,认出6块盘,import也成功,不过里面的lv全部改名了。名字不要紧,我们根据纪录再改回来。好,datavg恢复了正常。
我把reloadvg的7块盘转到另外一台机器上,在这边弄好了再搬回去。
新的机器也有个datavg,不过只有两块盘。好,cfgmgr之后,认出了新加的7块盘,然后做一次importvg,基本上可以模拟到原来那台机器的情况。大家认真看了,信息很多。
cfgmgr可以认到7块新盘:
root@dms3:/>lspv
hdisk2          00387cfa43915303                    rootvg          active
hdisk3          00339dad3dabcc93                    datavg          active
hdisk6          00387cfab3212477                    datavg          active
vpath6          none                                None
vpath7          none                                None
hdisk1          00387cfa438d460a                    None
hdisk4          00387cfa43917968                    None
hdisk5          00387cfa439184d4                    None
hdisk7          00387cfa439192ac                    None
hdisk8          00387cfa43944bb4                    None
hdisk9          00387cfa439452f5                    None
hdisk10         00387cfa439458c7                    None
vpath0          none                                None
vpath1          none                                None
vpath2          none                                None
vpath3          none                                None
vpath4          none                                None
vpath8          none                                None
vpath9          none                                None
然后做importvg:
root@dms3:/>importvg -y bvg hdisk1
PV Status:      hdisk1  00387cfa438d460a        INVPVID
                hdisk4  00387cfa43917968        INVPVID
                hdisk5  00387cfa439184d4        INVPVID
                hdisk7  00387cfa439192ac        INVPVID
                hdisk8  00387cfa43944bb4        PVACTIVE
                hdisk9  00387cfa439452f5        PVREMOVED
                hdisk10 00387cfa439458c7        INVPVID
                        00387cfa4397b72c        PVMISSING
                        00387cfa4d852bd0        NONAME
                        00387cfa4d852cdd        NONAME
                        00387cfa438d34ea        NONAME
                        00387cfa68e7824f        NONAME
                        00339dadea67f70e        NONAME
varyonvg: Volume group bvg is varied on.
0516-510 synclvodm: Physical volume not found for physical volume
        identifier 00387cfa438d34ea0000000000000000.
0516-510 synclvodm: Physical volume not found for physical volume
        identifier 00387cfa68e7824f0000000000000000.
0516-510 synclvodm: Physical volume not found for physical volume
        identifier 00339dadea67f70e0000000000000000.
0516-510 synclvodm: Physical volume not found for physical volume
        identifier 00387cfa4397b72c0000000000000000.
0516-510 synclvodm: Physical volume not found for physical volume
        identifier 00387cfa4d852bd00000000000000000.
0516-510 synclvodm: Physical volume not found for physical volume
        identifier 00387cfa4d852cdd0000000000000000.
0516-548 synclvodm: Partially successful with updating volume
        group bvg.
0516-1281 synclvodm: Warning, lv control block of lvdata
        has been over written.
0516-522 synclvodm: Unable to update logical volume fslv02.
0516-1281 synclvodm: Warning, lv control block of lvtranlog
        has been over written.
0516-522 synclvodm: Unable to update logical volume lvtranlog.
0516-1281 synclvodm: Warning, lv control block of lvdbbackup
        has been over written.
0516-522 synclvodm: Unable to update logical volume lvdbbackup.
0516-1281 synclvodm: Warning, lv control block of loglv01
        has been over written.
0516-522 synclvodm: Unable to update logical volume loglv03.
0516-1281 synclvodm: Warning, lv control block of lv_tsmdatabk
        has been over written.
0516-1281 synclvodm: Warning, lv control block of tsmdblv01
        has been over written.
0516-522 synclvodm: Unable to update logical volume lv00.
0516-1281 synclvodm: Warning, lv control block of tsmloglv01
        has been over written.
0516-522 synclvodm: Unable to update logical volume tsmloglv01.
0516-1281 synclvodm: Warning, lv control block of lv_dbbackup_m
        has been over written.
0516-522 synclvodm: Unable to update logical volume lv_dbbackup_m.
0516-1281 synclvodm: Warning, lv control block of lv_cmdbins1
        has been over written.
0516-522 synclvodm: Unable to update logical volume lv_cmdbins1.
0516-1281 synclvodm: Warning, lv control block of lv_db2fenc1
        has been over written.
0516-522 synclvodm: Unable to update logical volume lv_db2fenc1.
0516-1281 synclvodm: Warning, lv control block of lv_rmobject
        has been over written.
0516-522 synclvodm: Unable to update logical volume lv_rmobject.
0516-1281 synclvodm: Warning, lv control block of lv_ubosstg
        has been over written.
0516-522 synclvodm: Unable to update logical volume lv_ubosstg.
0516-1281 synclvodm: Warning, lv control block of loglv02
        has been over written.
0516-522 synclvodm: Unable to update logical volume loglv02.
0516-1281 synclvodm: Warning, lv control block of lv_cmdbplog
        has been over written.
0516-522 synclvodm: Unable to update logical volume lv_cmdbplog.
0516-1281 synclvodm: Warning, lv control block of lv_cmdbalog
        has been over written.
0516-522 synclvodm: Unable to update logical volume lv_cmdbalog.
0516-1281 synclvodm: Warning, lv control block of lv_tsmbk
        has been over written.
0516-522 synclvodm: Unable to update logical volume lv_tsmbk.
0516-1281 synclvodm: Warning, lv control block of lv_tsmdata
        has been over written.
0516-522 synclvodm: Unable to update logical volume lv_tsmdata.
0516-622 synclvodm: Warning, cannot write lv control block data.
bvg
PV Status:      hdisk8  00387cfa43944bb4        PVINVG
                hdisk9  00387cfa439452f5        PVINVG
0516-013 varyonvg: The volume group cannot be varied on because
        there are no good copies of the descriptor area.
我没用reloadvg的名字,随便用了个bvg的名字,但并非big vg。
我们来看看errpt:
root@dms3:/>errpt
IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION
5BEAD71B   0727220806 I S LIBLVM         Activation of a no quorum volume group w
26120107   0727220806 U S LIBLVM         PHYSICAL VOLUME DEFINED AS MISSING
root@dms3:/>errpt -a|more
---------------------------------------------------------------------------
LABEL:          LVM_QUORUMNOQUORUM
IDENTIFIER:     5BEAD71B
Date/Time:       Thu Jul 27 22:08:25 HKG
Sequence Number: 36421
Machine Id:      00387CFA4C00
Node Id:         dms3
Class:           S
Type:            INFO
Resource Name:   LIBLVM
Description
Activation of a no quorum volume group with out 100% of the disks
Probable Causes
One or more physical volumes are not available and MISSINGPV_VARYON variable is on
Detail Data
MAJOR/MINOR DEVICE NUMBER
0033 9DAD
SENSE DATA
0000 4C00 0000 0106 BF8E 93E9 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
---------------------------------------------------------------------------
LABEL:          LVM_MISSPVADDED
IDENTIFIER:     26120107
Date/Time:       Thu Jul 27 22:08:25 HKG
Sequence Number: 36420
Machine Id:      00387CFA4C00
Node Id:         dms3
Class:           S
Type:            UNKN
Resource Name:   LIBLVM
Description
PHYSICAL VOLUME DEFINED AS MISSING
Probable Causes
POWER, DRIVE, ADAPTER, OR CABLE FAILURE
Detail Data
MAJOR/MINOR DEVICE NUMBER
0000 0000
SENSE DATA
0000 0000 0000 0000 0000 0000 0000 0000
--------------
然后我用reloadvg的名字再做一次export和import,看看lspv和lsvpcfg:
root@dms3:/>lspv
hdisk2          00387cfa43915303                    rootvg          active
hdisk3          00339dad3dabcc93                    datavg          active
hdisk6          00387cfab3212477                    datavg          active
vpath6          none                                None
vpath7          none                                None
hdisk1          00387cfa438d460a                    None
hdisk4          00387cfa43917968                    None
hdisk5          00387cfa439184d4                    None
hdisk7          00387cfa439192ac                    None
hdisk8          00387cfa43944bb4                    reloadvg
hdisk9          00387cfa439452f5                    reloadvg
hdisk10         00387cfa439458c7                    None
vpath0          none                                None
vpath1          none                                None
vpath2          none                                None
vpath3          none                                None
vpath4          none                                None
vpath8          none                                None
vpath9          none                                None
root@dms3:/>
root@dms3:/>lsvpcfg
vpath0 (Avail ) 32025302 = hdisk1 (Avail pv )
vpath1 (Avail ) 32125302 = hdisk4 (Avail pv )
vpath2 (Avail ) 32225302 = hdisk5 (Avail pv )
vpath3 (Avail ) 32325302 = hdisk7 (Avail pv )
vpath4 (Avail ) 32425302 = hdisk8 (Avail pv reloadvg)
vpath5 (Def ) 30325302 = hdisk2 (Avail pv rootvg)
vpath6 (Avail ) 30925302 = hdisk3 (Avail pv datavg)
vpath7 (Avail ) 30A25302 = hdisk6 (Avail pv datavg)
vpath8 (Avail ) 32525302 = hdisk9 (Avail pv reloadvg)
vpath9 (Avail ) 32625302 = hdisk10 (Avail pv )

出现pvid冲突的正是hdisk8和hdisk9。但我importvg的时候是从hdisk1做的,唯一解释就是虽然我从hdisk1做importvg,但所以vgda做同步的时候,仍会跟随最新的timestamp的那个vgda。所以我用readvgda检查hdisk1和hdisk8上的vgda的timestamp的区别:
*=============== 1ST VGDA-VGSA: hdisk1 ===============*
*****************************************
VGSA at block 128
*****************************************
*****************************************
vgsa beg: timestamp 1150689111 (44961f57), 271466951 (102e41c7)
vgsa beg: timestamp Mon Jun 19 11:51:51 HKG:2006
*=============== 1ST VGDA-VGSA: hdisk8 ===============*
*****************************************
VGSA at block 128
*****************************************
*****************************************
vgsa beg: timestamp 1154053012 (44c97394), 616748793 (24c2d6f9)
vgsa beg: timestamp Fri Jul 28 10:16:52 HKG:2006
vgsa.pv_missing:        191
大家可以看到hdisk8确实比hdisk1要新。
所以,前路已经明朗化,原因也基本清晰。

先把最新timestamp的盘拿走:
root@dms3:/>rmdev -dl hdisk8
hdisk8 deleted
root@dms3:/>rmdev -dl hdisk9
hdisk9 deleted
root@dms3:/>lspv
hdisk2          00387cfa43915303                    rootvg          active
hdisk3          00339dad3dabcc93                    datavg          active
hdisk6          00387cfab3212477                    datavg          active
vpath6          none                                None
vpath7          none                                None
hdisk1          00387cfa438d460a                    None
hdisk4          00387cfa43917968                    None
hdisk5          00387cfa439184d4                    None
hdisk7          00387cfa439192ac                    None
hdisk10         00387cfa439458c7                    None
vpath0          none                                None
vpath1          none                                None
vpath2          none                                None
vpath3          none                                None
vpath4          none                                None
vpath8          none                                None
vpath9          none                                None
我们重做一次importvg,自然就会更新那个timestamp,然后再把问题硬盘加入,自然就会把有问题的vgda覆盖掉,呵呵。
root@dms3:/>importvg -y bvg hdisk1
0516-304 getlvodm: Unable to find device id 00387cfa43944bb4 in the Device
        Configuration Database.
0516-304 getlvodm: Unable to find device id 00387cfa439452f5 in the Device
        Configuration Database.
PV Status:      hdisk1  00387cfa438d460a        PVACTIVE
                hdisk4  00387cfa43917968        PVACTIVE
                hdisk5  00387cfa439184d4        PVACTIVE
                hdisk7  00387cfa439192ac        PVACTIVE
                hdisk10 00387cfa439458c7        PVACTIVE
                        00387cfa43944bb4        NONAME
                        00387cfa439452f5        NONAME
varyonvg: Volume group bvg is varied on.
0516-1281 synclvodm: Warning, lv control block of lvreloaddbbkup
        has been over written.
0516-622 synclvodm: Warning, cannot write lv control block data.
bvg
PV Status:      hdisk1  00387cfa438d460a        PVACTIVE
                hdisk4  00387cfa43917968        PVACTIVE
                hdisk5  00387cfa439184d4        PVACTIVE
                hdisk7  00387cfa439192ac        PVACTIVE
                hdisk10 00387cfa439458c7        PVACTIVE
                        00387cfa43944bb4        NONAME
                        00387cfa439452f5        NONAME
varyonvg: Volume group bvg is varied on.
好,意料之中,我们看见VG里少了两块盘,因为我们删掉了。其余的都active了,下面我们逐个加进来就是了。首先检查一下现在hdisk1的timestamp:
*=============== 1ST VGDA-VGSA: hdisk1 ===============*
*****************************************
VGSA at block 128
*****************************************
*****************************************
vgsa beg: timestamp 1154055815 (44c97e87), 416778508 (18d7890c)
vgsa beg: timestamp Fri Jul 28 11:03:35 HKG:2006
够新的了。lsvg再检查:
root@dms3:/>lsvg -o
bvg
datavg
rootvg
root@dms3:/>lsvg bvg
VOLUME GROUP:   bvg                      VG IDENTIFIER:  00339dad00004c0000000106bf8e93e9
VG STATE:       active                   PP SIZE:        64 megabyte(s)
VG PERMISSION:  read/write               TOTAL PPs:      4172 (267008 megabytes)
MAX LVs:        256                      FREE PPs:       113 (7232 megabytes)
LVs:            5                        USED PPs:       4059 (259776 megabytes)
OPEN LVs:       0                        QUORUM:         4
TOTAL PVs:      7                        VG DESCRIPTORS: 7
STALE PVs:      0                        STALE PPs:      0
ACTIVE PVs:     5                        AUTO ON:        yes
MAX PPs per PV: 1016                     MAX PVs:        32
LTG size:       128 kilobyte(s)          AUTO SYNC:      no
HOT SPARE:      no                       BB POLICY:      relocatable
root@dms3:/>lsvg -l bvg
bvg:
LV NAME             TYPE       LPs   PPs   PVs  LV STATE      MOUNT POINT
lvreloaddata        jfs        737   737   2    closed/syncd  /reloaddata
loglv04             jfslog     1     1     1    closed/syncd  N/A
lvreloaddb          jfs2       3000  3000  7    closed/syncd  /reloaddb
loglv03             jfs2log    1     1     1    closed/syncd  N/A
lvreloaddbbkup      jfs        320   320   2    closed/syncd  N/A
一切意料之中,好我们可以再搞问题盘了。



cfgmgr
rmdev -dl hdisk9
exportvg bvg
现在多了hdisk8,再做一次importvg
root@dms3:/>importvg -y bvg hdisk1
0516-304 getlvodm: Unable to find device id 00387cfa439452f5 in the Device
        Configuration Database.
PV Status:      hdisk1  00387cfa438d460a        PVACTIVE
                hdisk4  00387cfa43917968        PVACTIVE
                hdisk5  00387cfa439184d4        PVACTIVE
                hdisk7  00387cfa439192ac        PVACTIVE
                hdisk10 00387cfa439458c7        PVACTIVE
                hdisk8  00387cfa43944bb4        PVACTIVE
                        00387cfa439452f5        NONAME
varyonvg: Volume group bvg is varied on.
0516-1281 synclvodm: Warning, lv control block of lvreloaddbbkup
        has been over written.
0516-622 synclvodm: Warning, cannot write lv control block data.
bvg
PV Status:      hdisk1  00387cfa438d460a        PVACTIVE
                hdisk4  00387cfa43917968        PVACTIVE
                hdisk5  00387cfa439184d4        PVACTIVE
                hdisk7  00387cfa439192ac        PVACTIVE
                hdisk8  00387cfa43944bb4        PVACTIVE
                hdisk10 00387cfa439458c7        PVACTIVE
                        00387cfa439452f5        NONAME
varyonvg: Volume group bvg is varied on.
好,再检查hdisk8的timastamp:
*=============== 1ST VGDA-VGSA: hdisk8 ===============*
*****************************************
VGSA at block 128
*****************************************
*****************************************
vgsa beg: timestamp 1154057112 (44c98398), 470568853 (1c0c4f95)
vgsa beg: timestamp Fri Jul 28 11:25:12 HKG:2006
vgsa.pv_missing:        32
VGDA at block 136
*****************************************
*****************************************
vgh.vg_id:    00339dad00004c0000000106bf8e93e9
vgh.numlvs:      5
vgh.maxlvs:      256
vgh.pp_size:     26
vgh.numpvs:      7
vgh.total_vgdas: 7
vgh.vgda_size:   2098
vgh.quorum:      1
vgh.auto_varyon: 1
vgh.check_sum:   0
vgda hdr: timestamp 1154057112 (44c98398), 470568038 (1c0c4c66)
vgda hdr: timestamp Fri Jul 28 11:25:12 HKG:2006
**********  Logical Volume: lvreloaddata  ***********
lve.lvname:             0
lve.maxsize:            2048
顺便看到,里面的lv都正常了。(原来是datavg里面的lv)

好,最后我们把hdisk9认回来,又做一次import,这样所有的vgda都更新了。
root@dms3:/>varyoffvg bvg
root@dms3:/>exportvg bvg
root@dms3:/>importvg -y bvg hdisk1
bvg
root@dms3:/>lsvg bvg
VOLUME GROUP:   bvg                      VG IDENTIFIER:  00339dad00004c0000000106bf8e93e9
VG STATE:       active                   PP SIZE:        64 megabyte(s)
VG PERMISSION:  read/write               TOTAL PPs:      4172 (267008 megabytes)
MAX LVs:        256                      FREE PPs:       113 (7232 megabytes)
LVs:            5                        USED PPs:       4059 (259776 megabytes)
OPEN LVs:       0                        QUORUM:         4
TOTAL PVs:      7                        VG DESCRIPTORS: 7
STALE PVs:      0                        STALE PPs:      0
ACTIVE PVs:     7                        AUTO ON:        yes
MAX PPs per PV: 1016                     MAX PVs:        32
LTG size:       128 kilobyte(s)          AUTO SYNC:      no
HOT SPARE:      no                       BB POLICY:      relocatable
root@dms3:/>lsvg -l bvg
bvg:
LV NAME             TYPE       LPs   PPs   PVs  LV STATE      MOUNT POINT
lvreloaddata        jfs        737   737   2    closed/syncd  /reloaddata
loglv04             jfslog     1     1     1    closed/syncd  N/A
lvreloaddb          jfs2       3000  3000  7    closed/syncd  /reloaddb
loglv03             jfs2log    1     1     1    closed/syncd  N/A
lvreloaddbbkup      jfs2       320   320   2    closed/syncd  /reloaddbbkup
root@dms3:/>mount /reloaddata
root@dms3:/>mount /reloaddb
root@dms3:/>mount /reloaddbbkup
象征性检查一下hdisk9的timestamp:
*=============== 1ST VGDA-VGSA: hdisk9 ===============*
*****************************************
VGSA at block 128
*****************************************
*****************************************
vgsa beg: timestamp 1154057485 (44c9850d), 382885841 (16d25fd1)
vgsa beg: timestamp Fri Jul 28 11:31:25 HKG:2006
vgsa.pv_missing:        0
背景音乐响起。。。。。。。。。。。。
大团圆结局。



续集:
把这7块盘重新搬回到原来的机器上。
然后在新的机器上把要增加的两块盘认回来,把pvid改了,并且做一个新的vg,目的是把vgid也改了。然后把这两块盘搬到原来的机器上,认回来,extend到datavg里面。
原因:相同的pvid,不同的vgid,导致两个vg都混乱了。下回加盘要心细点。再追上去,就是800的问题了,原来这两块盘曾经做过flash copy,保留了reloadvg里面其中两块盘的信息,并且是绝对一样的信息。虽然有withdraw的过程,但里面的数据依然存在。
我又一次栽在flash copy的脚下。



问:为什么不HDISK8,HDISK9两个硬盘一起IMPORT回来?要分别import?
原因就是flash copy啊。它做出来的一对盘是完全一样的,所以pvid,vgid这些数据也一样。防范的方法就是我上面写的办法:先改pvid,再改vgid,然后再按平常的步骤进行。
因为第一次import的时候,两个pv的状态不相同:
root@dms3:/>importvg -y bvg hdisk1
PV Status:      hdisk1  00387cfa438d460a        INVPVID
                hdisk4  00387cfa43917968        INVPVID
                hdisk5  00387cfa439184d4        INVPVID
                hdisk7  00387cfa439192ac        INVPVID
                hdisk8  00387cfa43944bb4        PVACTIVE
                hdisk9  00387cfa439452f5        PVREMOVED
                hdisk10 00387cfa439458c7        INVPVID
                        00387cfa4397b72c        PVMISSING
                        00387cfa4d852bd0        NONAME
                        00387cfa4d852cdd        NONAME
                        00387cfa438d34ea        NONAME
                        00387cfa68e7824f        NONAME
                        00339dadea67f70e        NONAME

再分析一下:
上面看到的importvg的状态:
root@dms3:/>importvg -y bvg hdisk1
PV Status:      hdisk1  00387cfa438d460a        INVPVID
                hdisk4  00387cfa43917968        INVPVID
                hdisk5  00387cfa439184d4        INVPVID
                hdisk7  00387cfa439192ac        INVPVID
                hdisk8  00387cfa43944bb4        PVACTIVE
                hdisk9  00387cfa439452f5        PVREMOVED
                hdisk10 00387cfa439458c7        INVPVID
                        00387cfa4397b72c        PVMISSING
                        00387cfa4d852bd0        NONAME
                        00387cfa4d852cdd        NONAME
                        00387cfa438d34ea        NONAME
                        00387cfa68e7824f        NONAME
                        00339dadea67f70e        NONAME
因为当时的timestamp最新的是hdisk8,所以只有它自己正常,INVPVID表示这个pv根本不在这个vg里面,因为当时hdisk8里面的vgid是datavg,所以它们并不属于这个vg。NONAME表示这是这个vg里面的盘,但在本机上并不存在这个pvid。PVREMOVED表示这盘已经在vg里消失(这个比较难解释,但这就是我分开import的原因)。PVMISSING表示pvid对但vgid错。
总之一个vg里面有这么多种状态,我还是头一回遇到。
至于我上次栽的跟斗,也是相同pvid导致的pvmissing,详细请参阅那个寒假作业,呵呵。
[ 本帖最后由 炸鸡 于 2006-8-1 10:31 编辑 ]





本文来自ChinaUnix博客,如果查看原文请点:http://blog.chinaunix.net/u/19495/showart_149385.html
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP