由于我的自由和开放源码软件维护和行动主义工作，我拥有大量的IT足迹，以支持我所做的一切所需的服务和开发环境。不幸的是，我也是我自己的系统管理员，我在这方面非常糟糕。这是一个关于由于Linux mdraid缺陷和一个有故障的SSD，我如何使我的大部分服务离线并清除我的主目录的故事。希望这对将来的人有帮助，但如果没有，你至少可以分享一些宣泄。
如前所述，我有一个由多台服务器组成的集群，从AMD EPYC机器到ARM机器，再到我去年在AlpineConf上谈到的对Systemz大型机的极大兴趣。它们用于以虚拟机和容器的形式承载各种服务，在我的设置的当前迭代中，大多数容器由kubernetes管理。这些工作负载中的大多数都由Isilon NAS支持，但有些工作负载运行在本地存储上，通常是出于性能原因。
使用kubernetes在当时似乎是一件不需要动脑筋的事情，因为它可以让我为所有工作负载拥有一个统一的控制平面，而不管它们在哪里（以及在什么体系结构上）运行。从那时起，我意识到使用kubernetes管理我的服务的复杂性并不是因为我在工作负载中使用kubernetes所获得的好处，所以我开始从kubernetes迁移到管理系统和容器的传统方式，但许多服务仍然作为kubernetes容器进行管理。
我的主要开发服务器名为treefort。它是一款x86机箱，带有AMD EPYC处理器和256 GB内存。它在4TB三星860 EVO SSD上使用Linux mdraid进行了3路RAID-1设置。我使用KVM和libvirt来管理这台服务器上的各种VM，但服务器的大部分资源都专用于treefort环境。该环境还充当kubernetes worker，也是整个集群的kubernetes控制器。
最近我在特雷福遇到了一个失败。我订购了一根替换棒，并让一个朋友更换了它。一切似乎都很好，但后来我决定改进我的监控，这样我就可以对未来的任何硬件故障发出警报，因为由于未纠正的ECC错误导致随机事件在机器上崩溃并不有趣。在实施监控的过程中，我了解到其中一个SSD已从RAID中脱落。
我觉得这三个驱动器中有一个出现故障有点奇怪，所以我认为这只是因为维护，毕竟，可能是更换了柱塞杆后重新安装了驱动器。由于更换4TB三星SSD的零售价目前在700美元左右，我想我会将驱动器重新添加到阵列中，假设它在重建过程中再次出现故障，如果它真的出现故障的话。
然后，我检查了/proc/mdstat，它报告阵列运行正常。我对此一无所知，尽管回想起来，我可能会发现这一点可疑，但没有讨论阵列处于恢复状态，相反，它是健康的，有三个驱动器。不幸的是，我想“好吧，我想没关系”，就这么说了。
与此同时，由于速度原因，由本地SSD存储支持的treefort环境中的文件系统开始悄悄地自我损坏。因为我的大部分服务，比如邮件服务器、DNS和网络监控，都是在其他主机上运行的，所以实际上没有任何错误迹象。事情似乎基本上运行良好：我整个星期都在编译内核，测试针对Exeve（2）问题的各种缓解措施。当时我不知道的是，每次编译内核时，我都会越来越多地慢慢腐蚀磁盘。
我直到今天才意识到数据损坏的问题，不管怎样，当我登录到treefort环境时，我决定启动nano来完成我一直在做的一些需要在本周解决的工作。这让我大吃一惊：
毕竟，这让我担心，如果nano昨天还在工作，但什么都没有改变，为什么它会崩溃呢？所以，我用apk修复程序重新安装了nano，使它再次工作。在这一点上，我非常怀疑，服务器出现了问题，所以我立即杀死了所有在服务器上运行的来宾，并将重点放在裸机主机环境上（如果我们仍然使用Xen，我们将称之为dom0）。
我在treefort的卷上运行了e2fsck-f，希望一切顺利。我得到的不是一份干净的健康清单，而是很多文件系统错误。但这对我来说仍然没有任何意义，我再次检查了阵列，它仍然显示为完全健康。因此，我决定在卷上运行e2fsck-fy，并希望一切顺利。这占用了存储我的主目录的大部分卷。
库伯内特斯是一个反复无常的野兽，它假设你已经用冗余设置了一切，当然包括冗余控制器。当我让treefort离线时，我以一种艰难的方式发现了这一点，工作节点感到困惑，并将它们正在离线运行的服务也拿走，可能是因为它们无法与控制器对话。
最终，在朋友们的帮助下，我恢复了足够多的卷，使系统能够启动足够多的控制器，并恢复足够多的运行，以恢复不是treefort的workers上的服务，但就像我的主目录中的数据一样，在treefort上运行的服务可能会永久丢失。
首先，很明显，我需要改进我的备份策略，而不是“我以后再弄清楚”。我计划包装Rich Felker的胶木工具来实现这一点。
当然，房间里的另一个大问题是“你为什么不首先使用ZFS？”。虽然Alpine多年来一直支持ZFS，但由于CDDL许可，我一直不愿使用它。换句话说，从我使用GNU/Linux而不是实用主义的时候起，我就选择了灌输给我的关于GPL兼容性的咒语。我对这个决定的奖赏就是一团糟。虽然我认为Oracle、Illumos和OpenZFS的贡献者应该联合起来，重新授权MPLv2下的ZFS代码库，以解决GPL兼容性问题，但我开始认为我应该更关心拥有一种我可以信任的存储技术。
我也很确定我遇到的问题是mdraid中的一个bug，但也许我错了。我被告知有一个脏的位图系统，如果所有位图在好的一对驱动器和坏的驱动器上都被标记为干净，可能会导致这种大脑分裂问题，但我觉得这些位图上应该有时间戳来防止类似的事情。最好是因为时钟偏差而进行不必要的重建，而不是分裂大脑，让33%的读取由于与其他磁盘不同步而导致静默数据损坏。
尽管如此，我的计划是用另一家供应商的ZFS和SSD重建特雷福。无论三星固态硬盘发生了什么，都让我非常焦虑，我不想相信它们会继续生产使用。