背景 在安装了 debian jessie 的 X3500 IBM 服务器上，硬件 RAID 5（由服务器控制器创建）中的 4 个 SAS 磁盘之一损坏。从那时起，sda1（raid sda 磁盘上的一个结果分区）开始出现孤立 inode 问题。
过了一会儿，Debian 检测到 5 或 6 个 inode 孤儿并进入只读模式。操作系统保持运行，但许多服务不再能够写入磁盘并停止。
重新启动服务器可更正 sda1 并重新启动。短暂的等待后，服务器将使用孤立的 inode 重新启动，依此类推。
如果我以救援模式使用最小 lubuntu 启动服务器，则 fsck.ext4 -y / dev / sda1 成功结束。一切似乎都很好，系统重新启动，debian 再次启动，一切都运行顺利（除了 ProFTP 无法自行启动，但我必须重新启动它）半个小时，然后总是有 5/6 个 inode 孤儿，系统 sda1 以只读模式重新组装。我尝试将一些文件复制到 sda1，但下次重新启动时孤儿 inode 的数量要多得多。
我该如何摆脱这种恶性循环？我不明白这是硬件问题（为什么 SAS 控制器检测不到问题？）还是软件问题。
谢谢。伊利奇
PS：所有磁盘均使用 SAS 控制器进行测试。
答案1
我会更换驱动器。我的邮件服务器也遇到过类似的问题，实际上它好转了一段时间，直到灾难性地失败。（数千个孤立的 inode）就我而言，我认为这是一个文件系统问题，我通过运行 e2fsck 使问题变得更糟。我更换了驱动器，问题就解决了。
答案2
让我们总结一下我是如何（我想）解决问题的： - 我逐个测试了所有磁盘（SAS 控制器未检测到问题） - 我从 RAID 中一次移除一个磁盘，然后重新插入它，等待前一个磁盘在 RAID 中“重建”
我认为目标是第二个动作。我的假设（如果我是对的，请确认，如果我错了，请退款）是：阵列的第一个磁盘跟踪了第二个磁盘（在更换之前损坏的磁盘）的故障，并将其带到了欺骗 Debian 的后面。
从本质上讲，错误并不是真实存在的，而只是模仿出来的。
如果有关于该理论的最新消息和动态，我将及时向您通报。