昨晚刚处理的一个故障

收到告警后，检查发现所有接存储的小机均报大量下面的错误：

C62E1EB7   1017004715 P H hdisk2         DISK OPERATION ERROR

E86653C3   1017004715 P H LVDD           I/O ERROR DETECTED BY LVM

C62E1EB7   1017004715 P H hdisk2         DISK OPERATION ERROR

E86653C3   1017004715 P H LVDD           I/O ERROR DETECTED BY LVM

C62E1EB7   1017004715 P H hdisk2         DISK OPERATION ERROR

E86653C3   1017004715 P H LVDD           I/O ERROR DETECTED BY LVM

C62E1EB7   1017004715 P H hdisk2         DISK OPERATION ERROR

E86653C3   1017004715 P H LVDD           I/O ERROR DETECTED BY LVM

AIX6.1的系统，P6的小机。

处理过程如下：

1、由于所有主机都报这样的错，排除人为、某根光纤线或者HBA卡的原因；

2、首先怀疑磁阵出问题了，检查磁阵发现磁阵状态良好；

3、检查主机上的卷组和文件系统，发现卷组和文件系统都在，文件系统处于挂载状态，pv,vg 状态正常；

4、进入到对应的文件系统中，发现文件系统是read-only模式，没法写；

5、检查多路径信息，链路目前都正常；

-----这里说明一下，因为在半夜，从收到告警到登录到主机上进行检查时，中间有点儿准备的时间的；

5、先操作备机，打算重新umount下文件系统，有进程在，用fuser -kxuc 杀访问文件系统的进程时，备机突然中断，连不上了，怀疑是自动重启了，等了一会儿机器没起来，担心机器会卡住，马上安排人去机房查看；

6、开始处理主机无法访问的文件系统，这次不再用fuser -kx这种方式了，先用命令停程序，然后用kill的方式杀剩余的几个访问文件系统的进程；因远程有问题，这次由同事操作，操作顺利。

7、重新挂载文件系统后，读写权限恢复，业务开始恢复；

8、检查DB主机时，发现oracle数据库主机，因为用的裸设备，从出现IO问题，到IO链路恢复，数据库是自动恢复的，人工没有干预；

9、检查SAN交换机时，发现两台SAN交换机在同一时间都发生重启了，uptime显示才运行几个小时，算了下时间，SAN交换机重启时，正好是主机开始报IO错误的时间，原因算是找到了，业务也恢复了，本应该处理完毕了；

客户却抓住不放了，客户不去查为啥俩SAN交换机同时被掉电，一直问文件系统为啥会变成只读模式的，链路恢复后，怎么没自动恢复到正常状态，而需要人工排查那么长时间； 还问能不能把这种保护机制关掉。。。。