某局点CAS告警共享文件系统损坏的处理办法

CAS+ 共享文件系统，组网不涉及。CAS+ 共享文件系统，组网不涉及。CAS+ 共享文件系统，组网不涉及。CAS+ 共享文件系统，组网不涉及。CAS+ 共享文件系统，组网不涉及。

前台告警共享文件系统损坏

对于这个问题我们首先可以检查以下三点：

1、有没有在后台执行过dd操作或者其他IO性能测试，命令是什么？    // 可以在/var/log/operation中确认
2、有没有将LUN划分给非CAS的主机？                               // 需要在对应的存储管理软件上确认
3、有没有将原来的CAS主机重装为其他操作系统？

检查者三点的目的就是为了确认有没有什么操作可能导致文件头损坏。

为了确认可以使用hexdump命令具体检查共享文件系统的文件头，看有没有损坏。

示例如下：

假设是/dev/dm-1，对应的命令是：hexdump -C /dev/dm-0 | more
root@cvknode1:~# hexdump -C /dev/dm-0 | more
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00500200  66 d7 e3 5a 00 00 00 00  01 00 00 00 96 6b b8 18  |f..Z.........k..|
00500210  ae e5 14 12 aa 44 68 8d  90 dc 01 00 00 00 00 00  |.....Dh.........|
00500220  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

第一列表示在磁盘中的偏移，以十六进制表示，100000表示1M，后面是具体的值，每一行有16个字节。
这里就表示dm-1的前5M数据都是0。

正常情况下，可以看到右侧有显示“this is an ocfs2 file system”。

如果出现上面这种情况，可以确认文件系统头已经损坏。

解决方法：如果需要解决，需要有一个完好的共享文件系统，才能去修复。如果现在没有，只能从其他环境中dd文件头。

假设dm-0是异常的，dm-1是正常的，可以使用以下命令修复。

1， hexdump –C /dev/dm-0 | more 看存储的头信息，发现没有了ocfs2的信息，被改写成了UEFI；
2， 执行“dd if=/dev/dm-1 of=/dev/dm-0 bs=4096 count=2 oflag=direct”从正常存储卷dm-1复制数据头文件信息来修复dm-0
3， 执行fsck.ocfs2 –fpn /dev/dm-0，修复文件系统，但报错Bad magic number in superblock while opening "/dev/dm-0"，说明superblock有问题
4， 执行命令fsck.ocfs2 -r2 /dev/dm-0修复superblock
5， 到CAS页面上启动该存储池，一段时间后正常启动，业务恢复