登录系统看到界面上显示EXT3-fs error (device dm-0) in start_transaction: Journal has aborted，占满了整个屏幕。dmesg显示的也都是同样的错误。
messages日志中发现很多如下的报错：
Oct 1 20:35:32 ha2 kernel: lost page write due to I/O error on dm-0
Oct 1 20:35:32 ha2 kernel: scsi0 (0,0,0) : reservation conflict
Oct 1 20:35:32 ha2 kernel: SCSI error : <0 0 0 0> return code = 0x18
Oct 1 20:35:32 ha2 kernel: end_request: I/O error, dev sda, sector 19771733
Oct 1 20:35:32 ha2 kernel: Buffer I/O error on device dm-0, logical block 2445313
redhat答复：scsi 驱动报错 0x18 表示存储的 scsi 预留区出现了冲突。通常情况下导致该报错不排除存储设备把该存储区又划分给其他服务器使用的可能性。
以上是一台redhat as 4.8系统的服务器报的错，已经redhat给出的建议。但是我们出问题的文件系统之根文件系统，不可能是共享的LUN。在网上查找，发现redhat的一个bug和这个报错是一致的。bug id为468391。
这是一台很重要的生产服务器，最近连续两次出现这种问题，真的很头大。每次重启系统是能解决问题，但是不知道什么时候还会再出问题，不知道该怎么才能彻底解决？？
由 于这台服务器是运行在虚拟平台vmware上的，在vmware上也看到虚拟磁盘在文件系统只读的时候，被卸载又重新挂载过。我曾怀疑过是不是出现了路径 抖动，但是如果是路径抖动的话，应该所有运行在vmware上的虚拟机都会受到影响，而不可能只出现单独一台出问题。而这台vmware是版本 3.5.3，而vmware现在技术支持的最低版本是3.5.5，要想得到他们的技术支持只有升级vmware的版本，而升级操作对现在还没有测试环境的 我们来说，一时半会是不可能的。在vmware的网站的知识库中有相关问题的解决方法，但是不包括redhat4.8这个操作系统版本，在网上查询可以看 到有人遇到类似的问题，有个老外在文章中说需要修改内核代码，然后编译内核。把内核检测到路径异常，对系统隐瞒着异常，以便阻止文件系统错误。
与此同时，我们还同时联系了hp才存储技术支持，并把所有的存储信息发送过去，他们给出的结论是存储没有问题。真他妈的怪事！都说自己东西是正常的，没有任何问题，那难道文件系统变只读了，是上帝在搞怪不成。
