关于文件系统2G限制环境下文件大小达到2G后I/O方面情况的疑问

samshi

关于文件系统2G限制环境下文件大小达到2G后I/O方面情况的疑问

近来遇到一个问题，尽管是在pc server+redhat linux6.2环境下发生的，但是估计solaris下的情况可能也比较类似。

有9台业务不大重要的工控机，负荷非常轻，有个应用程序写debug.log日志较多，i/O频繁。
几台微机负载均衡，业务不大，所以一年来大家都没怎么碰它，这些机器uptime多半都有1年左右时间。

近日，集成商解决软件问题时将机器reboot了，结果大部分起不来了。我看了一下，都是遇到文件系统的问题了。进入单用户修复后问题得到解决。

反思问题的发生，首先我觉得几台机器文件系统布局不合理，只分了/boot、/、和swap，没有把经常变化的/var单独画划分来，结果时间长了/文件系统就遇到问题了。
这么多机器文件系统出现问题，我觉得不是偶然的，怀疑与2G文件系统限制环境下某个文件达到2G后的I/O有关，debug.log文件达到2g后没有继续变大，系统也没有任何报错提示。应用是否仍然在往debug.log里边写日志，2G的限制是否让应用进程长期往某些block里面I/O,实事上造成进程在往硬盘文件系统上“钻洞”的现象？

solaris8环境下,我的一些机器也会遇到nohup.out文件到了2g后不报错的现象，这类环境下I/O是怎么做下去的？
有朋友思考过这个问题吗？