之前已经实验出linux内存管理上的确存在弱点，但是对于为什么内存耗尽后不能重启应用服务象oracle，甚至不能重启系统，也不能杀死已经无效的应用进程感到不解。这次在dep服务器上在极少的内存环境中运行旧系统，看看极限可以承受到什么水平。这个系统在512M内存和PiiCPU，比一般的桌面机还要弱，但运行了包括oracle/java/web/等多个吃内存的老虎，撑到第三天终于挂了，在处理过程中发现导致上面不能重启是由于vfs在 flush/iupdate时由于内存耗尽不能完成进程，和超块死锁造成的。

　　把重启测试服务器应用的cron脚本中止后，第三天，终于看到这台服务器exhausted，这再次证明linux对内存（处理上的弱点）。随后做第二个实验，恢复每小时一次的脚本应用重启，但不让服务器两天一次重启，看看可以支撑多长时间。......还没完，那台服务器重启应用后完全不能响应，而打算重启服务器本身居然也不能关机。检查看有的进程，看来用光一次后，整个系统就象特级残废一样无法恢复正常了。（十分钟以后）在让管理员硬性重启后，系统仍然没有恢复正常，报告是需要手工Ctrol-D进行fsck操作，这也是题中应有之意。但到机房进行操作，顺便加上一两G内存时，却碰上了意外的情况。

　　首先是不同的内存条（频率是一样的）冲突，不知为什么，却是反应为scsi硬盘寻不着道，换成同一品种后故障消失了。随后在识别几十个mount点时碰到困难——我是很讨厌那种不是使用设备标识符而使用label的fstab的，不得不一个个地查那个label对应那个标识符。最后完成后启动，ls却发现 "/"所有文件都不见了。badblock也找不到坏区，似乎是ext2链表乱了。在这个问题上翻天下地弄了差不多两个小时，默驴技穷，看来如果不是强行 fsck 根目录，就得重装根目录，然后再重整旧文件，不过这是非常危险的操作，八成等于系统重装。正在没有辄的时侯，发现dir却是有响应的：莫非是显示器没有能够显示目录色彩所以隐形了？抱着最后一丝希望把另一辆小车上的显示器推过来一接，咳，就是。瞧，显示器的质量也是可以害死人的，差点让我把一个还算是好的系统重装了。

　　回顾这次和以前若干次在另外的主机上的同样尝试，表明一旦 linux的内存用光后，除了新的应用请求分配内存需要等待外，更重要的是，会造成vfs进入死循环等待。估计是由于kflush以前形成高速缓存时由于没有请求到新的内存，所以锁死的某一个超块始终不能释放；其他要访问类似超块的进程也只好干等待；另一方面由于不能最后完成flush写入，进程也不能清空。这时，对于系统来说，就是原有的IO进程没有完成，这样，linux就会忽略所有的kill signal 6重启信号，等这些进程完成。这样就进入我已经重复出来的一旦内存 exhausted后不但所有应用不能恢复，就算把部分进程杀掉清出内存，也没有看出该死锁释放的迹象；或者下一次我应该多等一段时间。问题是，目前我没有找到很好的在实验室重复这种极限状态的方法，每次碰到都是在工作系统高峰时，这时侯总是急不可待要恢复系统。