很多时候数据的丢失不光是由一个事情出了错引起的，而是由一连串的诱因共同导致。
不过最近我把自己的一个加密 root 系统分区搞坏了，所以无论如何至少我又多了一个理由来 blog 上写东西233

PS: 丢掉的数据里好像有两篇帖子的草稿（划掉划掉

这台系统是我的主力机，Arch Linux 加上稍微调整过超频的 AMD CPU 和 GPU。在一块 NVMe 固态上用着 LUKS2 模式的 dm-crypt 加密的根文件系统，绑定了我之前写过的 systemd TPM2 Policy 解密方式。里面的文件系统是 zstd:3 压缩模式的 btrfs
或许你已经在想很多种出问题的方式了，但实际情况其实还是复杂了不少的

嘛，要从哪里开始说起呢

Btrfs 中损坏的数据

事情的起源并不来自于 dm-crypt 而是上层的文件系统。
虽然很匪夷所思，但这一两个月以来这台电脑在大范围更新系统的时候经常抛出错误（”Truncated tar archive”），由于出现后 pacman 并不会认为这个包安装失败了，所以在这段时间里它已经损坏了几个软件包，导致后来我见到这个报错都是直接打开新的终端单独重新安装一下出错的包

同样还出现过一次的是 kernel panic… 报错说 btrfs 的 b-tree 爆炸了，但重启后什么问题都没有，btrfs check 之类的都能通过。虽然疑点重重但后来也没有重建文件系统，毕竟太麻烦了。

但这样的问题似乎就一直存在着存在着，没有任何重要文件被损坏了，除了 pacman 外也没有其他异常。我记得好像有一个 arch forum 上的帖子说可能是硬件问题，但分区上也没有坏块。
直到有一天更新完系统后整个 KDE 桌面崩溃了，很多设置组件和整个显示设置都少了很多。或许是时候丢掉现有的文件系统了吧

之后就是提取所有 root 文件系统下的文件到一块独立的储存上打包成了 .tar 准备重建文件系统。这块储存倒是很可靠，这么长时间了一点问题也都没有，倒是让我相信了现在的处境是文件系统的问题。
创建文件系统重新解压数据，最后确认一下 fstab 和 bootloader 整个过程除了等还是等。不过这次我选了 xfs 当做文件系统，毕竟相信一个凶手在没有任何变化的情况下不杀掉数据是不现实的（而且当时我也在尝试用 Red Hat 生态的服务器系统，xfs 是它们的默认值）

但问题还是存在，而且没有了内置的文件透明压缩，磁盘占用量高了两倍左右

从 KDE 崩溃到问题的开始其实已经很近了，被这么折腾了一大圈真的好累好累。这是第一个诱因

我是怎么用 Syncthing 的

年初的时候我就有琢磨过怎么备份才是最好的解决方案：
用端到端加密在自托管的云服务器上安全的储存和同步文件的思路

但到后来由于 webdav 在同步方面的各种不方便，就用起了 syncthing 来同步 keepass 的数据库，而帖子的主角也就是那块 root 分区的 LUKS2 恢复密钥就存在其中。
Syncthing 是一个去中心化的本地（好像也可以 relay）文件同步软件。每个客户端只要连接着彼此他们之间的更改就都可以被几乎及时的同步到其他客户端

在我的网络里有一个笔记本、一部手机、还有这台主力电脑。考虑到笔记本的开机时间大概率会和主力机错开，所以我一直都依赖手机在两者之间做缓冲，而且这样手机本身也可以查看密钥嘛

问题是…
Syncthing 如果在手机上一直启动会特别耗电…… 电池续航–
这也就导致了在整个网络中，数据能被同步的窗口从近乎90%下降到了<50%。到这里事情就已经开始不妙了

但还有更不妙的…
给手机初始化了系统，所以里面少了很多软件或者有些没有被配置。比如 syncthing…

至此，网络中的同步就开始完全依赖与主力机和笔记本同时开机了，没有任何其它冗余。而这也意味着在没有主动同时打开笔记本的情况下数据是很难离开主力机的

鼓捣 TPM2

紧接着的一两天内我又在看 systemd 的 systemd-cryptenroll 要怎么在已经用上 TPM2 Policy 的同时绑定一个固定的 PCR 值，这并不是重点。
但在鼓捣的同时，出于某些原因我重新生成了一个新的恢复密钥并添加了一个临时密码用来快速输入去测试其他解密方式。而新的恢复密钥则和旧的一样放到了 keepass 数据库里

然后就是…

  • 我觉得这可以
  • 试一下，不可以
  • 这样肯定可以了，唉。顺便删掉临时密码，毕竟还要重启一次好麻烦
  • 诶，怎么还是不行
  • …恢复密钥

所以恢复密钥会在哪里呢？

当当当当，只有加密分区里有最新的版本。
同步系统的冗余失效了，其它冷备份在需要最新数据的场景下也显得相当无力。面对64个随机字符的恢复密钥，唯一的选择只有删除分区

CPU PBO 配置的问题？

之后在准备装新系统的时候打算把电脑里的 windows 和 linux 都重装一下，前者已经因为 bug 更新不了了，后者已经消失了嘛

但这时突然发现 windows 的安装过程一切顺利，但另一边新选的 Fedora 在用 btrfs 时安装会报错，而且是和 Arch 下一模一样的问题：”Truncated tar archive”
Fedora 作为 Red Hat 系列发行版的最上游，虽然发布节奏超快但发行版自身的组件相当稳定，就像 Ubuntu 非 LTS 那样。第二次重试安装后，安装时报错的包名甚至不一样了。到这里我才意识到，原来问题的根源来自硬件

想要 debug 最好的入手点就是找找我改过什么。AMD CPU 的 PBO 机制和 Intel 的睿频类似，只是可以更加细致的控制怎么提升频率，电压和频率的关系是怎么样的。
其中有个功能叫做 Curve Optimizer，一般用来欠压超频用，可以稍微省点电。这个值应该只是计算公式中的一部分，根据之前的测试，我的个这台电脑的设置是全核心 -20。但经过这件事后我就去找了正经工具测试了一下稳定性：sp00n/CoreCycler

结果反复测试发现，整个 CPU 只有一个核心的体制甚至不能支撑到 -10 的欠压，但其它核心都能跑在 -20 以下。
由于我之前给这颗体制很烂的核心也设置了 -20。在实际场景中就导致了只要有极重负载的计算落到这颗核心上持续的时间只要长过5秒就一定会返回错误结果。有一个场景很符合这种“极重负载”，加密和压缩，dm-crypt 和 btrfs 的 zstd 压缩全都占了。
可能这也是为什么之前小批量更新软件就不会出问题吧，负载分摊到这颗烂核心上的概率稍微小一些，而且即使有持续时间也不长

那现在怎么样了呢

咕咕了很多天后，所有的事情都在被逐一解决。先是在本地常开的小服务器上跑了 syncthing 的节点，这样只要设备在家里就99%可以同步数据。加上之前给其它服务们用的 tailscale 网络，即使不在家里同步机会也相当的多

另外也在其它方面上改变了对待各种长期不变的“密钥”类数据的备份方式，不在依赖于单一备份手段了。更何况这个“备份”手段主打的功能是“同步”呢，意义上就不一样

最后就是把主力机从 Arch Linux 换成了 Fedora，我真的不知道这是不是个正确的决定，但… 我喜欢系统，不代表要天天被系统玩弄做那些学不到新东西的事情。Arch 教会了我超多的知识，但当明白了之后剩下的恼人成分反而侵蚀了日常。
不过 Arch 以后还是会在某些地方用的啦，我对系统的看法真的相当因地制宜233

终于…
可以清静一阵子了么