今天凌晨接到值班人员的电话，说一个应用系统出问题了，紧接着应用维护人员就把电话打过来了，说应用服务器文件系统只读了。最近碰到了好几次文件系统只读的问题，所有也没太在意就给他说把系统重启一下就应该可以了。

没 想到悲剧由此产生，过了一会应用管理员给我打电话说，由于系统运行了有很长一段时间了，系统的重启的过程中需要检查文件系统，当检查到20%左右的时候， 报错了。需要手工输入root密码或者键入ctrl+d进入系统，手动修复系统。我只好从被窝里爬起来***连到服务器上操作，当我输入密码时，更大的悲 剧出现了，输入的密码不起作用，键入ctrl+d后系统直接重启了。

没办法了，只有去公司一趟了。晚上打车太方便了，几分钟就到公司了，先给redhat技术支持打了个电话，说明情况。他们说这样的情况只能通过光盘引导，备份相关文件后，使用命令强制修复文件系统。

于 是找到原来安装系统的iso镜像，挂载到服务器上，重启服务器到rescue模式，原来的文件系统内容都在/mnt/sysp_w_picpath下，于是执行出 chroot /mnt/sysp_w_picpath ，然后使用使用fsck命令修复文件系统，报了很多indoe的信息，也不管那么多了，系统已经启动的备份机器上了，一路狂按Y，直到修复完成，重新启动 系统，系统正常了。

但是问题到此并没有结束，戏剧性的事情有开始了。当系统启动完成后，观察没有任何的问题了，应用系统回迁时，文件系统有 只读了，当再次把应用系统迁移到备机上时，发现当启动应用时备机的文件系统也神奇般的只读了。我当时汗都快出来了，从来没见过这样的问题，真的有点不知所 措的感觉。就这样在两台机器之间来回迁移了几次之后，应用系统又在主服务器上正常运行了，也没有再出现报错。

在这还要说一些东西，我们的系 统是运行在vmware esx上的，在适应esx的第一年里，一次问题都没有出现过，刚过了一年就问题不断。而且我们在物理机器上的linux系统有的都运行好几年了，现在还很 正常。看来虚拟化还是有很多问题的。准备周一的时候再找厂家问个清楚。