+ -
当前位置:首页 → 问答吧 → 有人能看的出这个VXVM的宕机原因吗

有人能看的出这个VXVM的宕机原因吗

时间:2010-06-08

来源:互联网

WARNING: /scsi_vhci/ssd@g600a0b8000336310000002d948e4398b (ssd13):
        i/o to invalid geometry

WARNING: /scsi_vhci/ssd@g600a0b8000336310000002d948e4398b (ssd13):
        i/o to invalid geometry

WARNING: /scsi_vhci/ssd@g600a0b8000336310000002d948e4398b (ssd13):
        i/o to invalid geometry

WARNING: /scsi_vhci/ssd@g600a0b8000336310000002d948e4398b (ssd13):
        i/o to invalid geometry

WARNING: /scsi_vhci/ssd@g600a0b8000336310000002d948e4398b (ssd13):
        i/o to invalid geometry

WARNING: /scsi_vhci/ssd@g600a0b8000336310000002d948e4398b (ssd13):
        i/o to invalid geometry

WARNING: /scsi_vhci/ssd@g600a0b8000336310000002d948e4398b (ssd13):
        i/o to invalid geometry

WARNING: VxVM vxio V-5-0-196 Kernel log update failed: Volume radius_vol detache
d
WARNING: VxVM vxio V-5-0-3 Volume radius_vol block 16:
        Uncorrectable write error on Subdisk SUN6140_0_4-01 block 16
WARNING: msgcnt 1 mesg 039: V-2-39: vx_writesuper - /dev/vx/dsk/radiusdg/radius_
vol file system super-block write error
WARNING: msgcnt 2 mesg 031: V-2-31: vx_disable - /dev/vx/dsk/radiusdg/radius_vol
file system disabled


panic[cpu24]/thread=30005799260:
forced crash dump initiated at user request


000002a102cad960 genunix:kadmin+4a4 (b4, 0, 0, 1225400, 5, 0)
  %l0-3: 000000000182b400 00000000011ddc00 0000000000000004 0000000000000004
  %l4-7: 0000000000000438 0000000000000010 0000000000000004 0000000000000000
000002a102cada20 genunix:uadmin+11c (60037c83e60, 0, 0, ff390000, 0, 0)
  %l0-3: 0000000000000000 0000000000000000 00000000488c0000 000000000000488c
  %l4-7: 0000000000000001 0000000000000000 0000000000000005 0000030005799260

syncing file systems...
12
8
done
dumping to /dev/md/dsk/d20, offset 3357409280, content: kernel

业务切到B机去了 B机上面vxvm的状态是完全正常的
主机messages里面没有任何报错信息 只有正常启动的信息 机器是忽然自己reset的
这个是crash  msgbuf.0的信息
存储确认过了 没有任何问题 硬件都是正常的
这个感觉非常奇怪啊 是不是什么BUG啊 有高人能看出来吗

作者: webber121   发布时间: 2010-06-08

我发现SUN 现在有很多hang机 是没有任何报错信息的 就是设置了deadman 也经常没有crash信息

作者: webber121   发布时间: 2010-06-08

去看看coredump吧 没信息的话只能看那个了

作者: zhmzhouming   发布时间: 2010-06-08

1.检查该主机ssd13磁盘对应的链路;
2.检查ssd13对应的VM磁盘;
3.检查/dev/vx/dsk/radiusdg/radius_vol的文件系统;
4.检查系统补丁及VxVM补丁是否需要更新。

最后,给LZ个建议,提问的时候把自己的软硬件环境描述下,出问题前做过什么操作之类的!

作者: 东方蜘蛛   发布时间: 2010-06-08

panic[cpu24]/thread=30005799260:
forced crash dump initiated at user request


000002a102cad960 genunix:kadmin+4a4 (b4, 0, 0, 1225400, 5, 0)


是不是安装了vcs呀,这个panic是由第三方软件发起的,


看前边有些io 报错,可能是io报错引起vxvm dg不可访问,应用检测到卷不可访问而触发panic

作者: doging   发布时间: 2010-06-08

估计是盘的backup信息出问题了,不能正常识别硬盘,导致panic了

作者: easybegin   发布时间: 2010-06-08

我也是怀疑这个第3方软件 但是是VXVM这个层面还是应用这个层面了 就搞不清楚

作者: webber121   发布时间: 2010-06-08

蜘蛛 这个radius_dg切到B机后 状态完全正常

dg radiusdg     default      default  20000    1261807700.102.shAAA01

dm SUN6140_0_10 SUN6140_0_8  auto     65536    1572732672 -
dm SUN6140_1_2  SUN6140_1_2  auto     65536    1572732672 -

v  radius_vol   -            ENABLED  ACTIVE   1572730880 SELECT  -        fsgen
pl radius_vol-01 radius_vol  ENABLED  ACTIVE   1572730880 CONCAT  -        RW
sd SUN6140_0_10-01 radius_vol-01 SUN6140_0_10 0 1572730880 0      SUN6140_0_8 ENA
pl radius_vol-02 radius_vol  ENABLED  ACTIVE   1572730880 CONCAT  -        RW
sd SUN6140_1_2-01 radius_vol-02 SUN6140_1_2 0  1572730880 0       SUN6140_1_2 ENA


还有最新的EIS好象没有给vxvm 5.0 for mp1的什么补丁 我在里面只找到了for mp3的补丁 这个VERITAS的版本是5.0 for mp1的

所有的连路都是正常的 不然不会切过去后 B机器运行了很长一段时间了 都没有报错

主机构架是2台 T5220和2台6140做的双机 存储之间用VXVM做了mirror
双机软件是VCS的 版本是5.0 for MP1

作者: webber121   发布时间: 2010-06-08



QUOTE:
估计是盘的backup信息出问题了,不能正常识别硬盘,导致panic了
easybegin 发表于 2010-06-08 11:29




   这个有办法解决吗 这个VXVM的文件系统是vxfs veritas自己的文件系统

作者: webber121   发布时间: 2010-06-08

WARNING: msgcnt 1 mesg 039: V-2-39: vx_writesuper - /dev/vx/dsk/radiusdg/radius_
vol file system super-block write error
WARNING: msgcnt 2 mesg 031: V-2-31: vx_disable - /dev/vx/dsk/radiusdg/radius_vol
file system disabled

我是感觉应用把VXVM跑崩的了 感觉是因为文件系统那里某些值不够 达到了极限 所以就切过去的了 而且宕机的时候正是业务最高峰的时候
有没有人有类似的经验
其实我在考虑2个6140的LUN做mirror 哪怕就是某一个6140的连路完全坏的了 因为不应该影响业务 不然mirror就没意义了

作者: webber121   发布时间: 2010-06-08

我感觉VXVM的命名方式采用ENCLOSUER方式看磁盘这么别扭呢,为什么不该成cxtydz的模式呢?实际上哪种方式命名的多啊?

作者: Tdog   发布时间: 2010-06-08

cxtydz 这样不好 因为是光纤路径 cxt后面东西很多很多 看的累人
如果真有必要,其实可以用vxdisk path list去识别就可以了

作者: webber121   发布时间: 2010-06-08



QUOTE:
cxtydz 这样不好 因为是光纤路径 cxt后面东西很多很多 看的累人
如果真有必要,其实可以用vxdisk path li ...
webber121 发表于 2010-06-08 12:15




             那enclouser的命名方式很容易区分哪个盘是哪个enclouser的么?

    vxdisk path list这个命令没用过,输出时什么样的?

作者: Tdog   发布时间: 2010-06-08

jbod

作者: dongchaojun   发布时间: 2010-06-08