遇到这种诡异的问题确实头疼，结合你描述的场景（RHEL/CentOS6系统、磁盘空间充足、重启后恢复），给你整理几个针对性的排查方向，一步步来定位：

1. 先排除inode耗尽的可能性 #

虽然你说磁盘空间充足，但Linux文件系统里，inode是存储文件元数据的独立资源，哪怕磁盘有剩余空间，inode耗尽也会导致文件写入异常（不过通常连创建文件都会失败，但还是要确认下，避免特殊场景）。

• 执行命令查看全部分区的inode使用情况：df -i
• 重点关注应用日志、文件所在的分区，看IUse%是否接近100%

2. 检查进程的文件描述符限制 #

应用运行中可能耗尽了进程级的文件描述符（FD），导致无法向已打开的文件写入，或者无法分配新的描述符完成写入操作（虽然创建/删除文件可能用了临时FD，刚好没触发上限）。

• 先找到应用的进程ID（PID），比如用ps aux | grep <你的应用名>
• 查看该进程的文件描述符限制：cat /proc/<PID>/limits，重点看Max open files的软/硬限制
• 统计该进程当前打开的文件描述符数量：lsof -p <PID> | wc -l，如果这个数值接近限制值，就说明是FD耗尽的问题
• 同时检查系统级的FD配置：cat /etc/security/limits.conf，看是否有针对应用用户的nofile设置；还有内核参数sysctl fs.file-max

3. 排查SELinux的拦截规则 #

RHEL6/CentOS6默认启用SELinux，很可能是某个临时的上下文变化或规则触发了写入拦截，但允许创建/删除操作。

• 先临时关闭SELinux测试：setenforce 0，然后观察应用是否能正常写入文件
• 如果关闭后恢复正常，说明是SELinux的问题，接着查看审计日志找具体的拒绝条目：
  • 实时查看审计日志：tail -f /var/log/audit/audit.log，搜索包含denied的行
  • 用工具分析AVC拒绝事件：ausearch -m avc，根据输出调整SELinux规则（比如用chcon临时修改上下文，或semodule添加自定义规则）

4. 检查磁盘IO及文件系统错误 #

哪怕磁盘空间够，也可能出现临时的硬件IO异常、文件系统损坏，导致写入失败但不影响创建/删除操作。

• 查看内核日志里的磁盘错误：dmesg | grep -i error，找类似IO error、sector相关的报错
• 查看系统日志：tail /var/log/messages，搜索磁盘、文件系统相关的异常信息
• 检查分区挂载状态：mount，确认目标分区没有被意外挂载为ro（只读），虽然你说能创建删除，但还是要排除特殊情况
• 只读检查文件系统完整性：e2fsck -n /dev/<你的分区设备名>（注意不要在挂载状态下执行写检查，需要重启到单用户模式再做完整检查）

5. 排查应用自身的文件操作逻辑 #

有时候问题出在应用代码本身，比如文件句柄泄漏、写入时未处理错误、文件被锁定等：

• 检查应用日志文件是否被其他进程锁定：lsof <你的日志文件路径>，看是否有其他进程持有该文件的写锁
• 查看应用的代码逻辑，确认写入操作是否有错误重试机制，是否在写入后主动调用flush/fsync刷新缓冲区（如果缓冲区无法刷新，也会导致写入停滞）
• 尝试在问题复现时，用strace -p <PID>跟踪应用的系统调用，看写入操作返回的错误码是什么（比如EPERM、ENOSPC、EIO等，这能直接定位原因）

6. 排查内核及系统级的隐性问题 #

RHEL6是比较老旧的系统，可能存在一些已知的内核或文件系统bug，导致这种异常：

• 检查是否有OOM Killer触发：dmesg | grep -i oom，虽然应用没崩溃，但OOM可能导致某些内核资源异常
• 查看是否有内核模块或系统服务异常：service --status-all，检查存储相关服务（比如lvm2、multipath）是否正常运行
• 可以尝试升级相关内核补丁，Red Hat针对RHEL6有不少文件系统相关的修复补丁，可能能解决这类偶发问题

内容的提问来源于stack exchange，提问作者nnnn