介绍
最近，我的一个系统在硬件 RAID6 的 LVM 上使用 ext4 时发生了灾难性的故障。以下是一些灾难：几个文件系统无法修复，至少有一个被授予通往天堂的梯子。这真的让我大吃一惊！我认为这种设置足够有弹性，可以承受更糟糕的情况，事实证明，在 7 年的更换故障硬盘过程中，它没有出现任何故障。但最近它却坏了。太严重了。
检查了与这次故障有关的所有信息后，我无法得出结论，不知道什么地方可能出现故障，最重要的是，为什么会出现故障。我希望有经验的人能找出原因和原因。以下是收集到的所有信息。
活动过程
当地时间大约 10:45，由于区域电网故障，我们大楼的电力供应中断。在电池运行了大约 40 分钟后，我们决定关闭服务器，因为没有预计的电力恢复时间。这绝对是一次干净的关闭，因为那时我们还有 20 分钟的时间电池就耗尽了。这些服务器不是关键任务服务器，因此在等待电力恢复时离线是可以接受的。后来这些服务器又恢复了在线状态。这台特定的服务器在启动时有 1 个硬盘发生故障。使用 RAID6 时，我并不担心，因为需要 2 个硬盘才能发生故障，这种情况极不可能发生，直到我得到替换件。像往常一样，我移除了故障硬盘，并允许服务器继续使用降级的 RAID6。过了一段时间，我意外地发现 LDAP 无法启动，因为它的数据文件夹缺少权限+r。这很奇怪，但很容易修复。为了确保万无一失，我检查了其他服务，它们都没有问题。后来，作为维护的一部分，该服务器重新启动了一次，并启动了 RAID 一致性检查以防万一。当地时间 18:00，一位同事在该服务器上对我们的一项服务进行了一些工作，并向我保证，该服务完全正常运行。当地时间 21:00 左右，他给我发消息说，某项服务突然丢失了样式，不允许他进入。起初我以为这是同样神秘的+r权限丢失，但发现静态文件夹完全丢失了。我认为这仍然是一个微不足道的修复，并推迟到第二天早上，完全不知道发生了什么事情。第二天早上，我面临着绝对的灾难，而不是简单的修复我想到了昨晚的事（必须说那是一种难以表达的感觉）。
值得注意的是，其他服务器在这次事件中毫发无损。其中一个服务器在软件 RAID10 的 LVM 上安装了 ext4，另一个服务器使用的是裸硬盘。
检查日志后，我发现大约在 20:05 时，PostgreSQL 开始无法写入数据，原因是文件消失类型错误。但是我们在 20:00 安排了备份。显然 I/O 负载很重。备份也因同样的错误而失败。很快ext4_lookup错误开始向系统日志发送垃圾邮件，所有其他服务也开始失败。最后，该服务回复了随机的乱码页面，没有任何样式的页面只是浏览器客户端提供的缓存副本。
故障模式
RAID6 报告性能下降，但从未报告失败。两者都未报告任何一致性检查错误。因此从硬件角度来看，它不是最优的，但绝不会失败。
正如我已经通过链接指出的那样，文件系统以某种可怕的方式失败了。有趣的是，只有硬件 RAID6 上的 LVM 上的 ext4 文件系统受到影响。RAID6 之外的其他文件系统（在 SSD 上）完好无损。已发现的文件系统故障问题包括：
- 一些目录和文件成为特殊文件（套接字和设备文件）
- 一些文件变成了目录（一个目录中的多个文件变成了另一个目录中的目录），反之亦然，目录变成了普通文件
- 有些目录同时成为彼此的父级和子级
- 有些文件被标记为正在使用并被删除
- 一些文件彼此之间有块交换（看到一个 syslog 文件由属于 apache 和内核日志的行组成，与另一个显然不属于那里的二进制数据交织在一起）
- 一些正在使用的 inode 引用了超出最大块数的块数
- 一些正在使用的 inode 多次重复引用相同的块号（或其中的某个范围）
- 一些正在使用的 inode 在元数据中具有完全随机的数据（日期、UID/GID 等）
其中一些要点可能是尝试使用 e2fsck 修复文件系统的结果，而其他一些则显然是损坏本身。检查 inode 后，我发现在有效 inode 周围有一些不幸的 inode，其元数据中充满了随机数据。我发现文件被随机损坏并非巧合：无论它们是新的还是已有 10 年历史的，正在使用的还是长时间未触碰的——每种文件都遭受了损害，相反，各种文件也都有幸存者。
根据文件系统故障列表，可以推断出某些库混在一起了，因此 Apache 的服务输出完全是乱码。此外，我无法恢复 PostgreSQL 数据，因为它的文件完全是一团糟。幸运的是，我可以修复 MySQL 数据，因为它只有系统元数据损坏，这相对容易重建。同样幸运的是，LDAP 数据目录只有访问日志损坏，这很容易重建。dpkg已安装的软件包列表与其他二进制数据混在一起。等等等等……
性能计数器图表也停止在大约 20:05，但除了文件操作通常的 I/O 增加之外，没有显示任何意外活动。
采取的额外措施
- 在服务器 RAM 上运行 memtest 未发现坏内存
- 找不到任何方法来测试 RAID 控制器内存
- 更换了故障硬盘，重建完成后再次运行一致性检查，结果显示硬件方面没有错误
- 我设法从 RAID 控制器中提取了低级日志，这两天没有出现任何警告或错误
- 重新安装所有软件包以覆盖任何损坏的数据
- 检查了系统中是否存在可疑进程，但没有发现任何异常
- 几周过去了，我仍在尝试修复损坏的文件系统
结论
我当然怀疑是病毒，但性能计数器根本没有发现任何异常活动，而且在检查系统时也没有发现任何证据。
鉴于损坏文件年龄没有巧合，我相信这不是 ext journal 故障。考虑到损坏的数据和元数据数量巨大，我认为服务器 RAM 或 RAID 控制器 RAM 不太可能损坏此文件，因为损坏的数据量比两个 RAM 的总和要多几个数量级。即使是随机填充的 inode 也不在某个特定区域，而是遍布整个卷。所有这些让我得出结论某物应该取得了RAID 控制器写如果它坚持要求硬盘读取有效数据（RAID 校验和会检测到错误），那么所有这些随机数据都会被写入硬盘，但我无法想象这种情况会发生。
因此，我请求任何有经验的人分析所提供的信息，看看他们是否能够找出故障及其原因，或者也许能就我尚未采取的任何步骤提供建议，以找出故障及其原因。
附言：请注意，这个问题与备份无关。