Qine
1
环境：Arch Linux + LUKS2 + Btrfs
背景：主盘 cryptroot，新盘 cryptroot2（使用主盘 /etc/cryptsetup-keys.d/nvme1.key 加密）。btrfs device add 后执行了 btrfs balance，随后重启。
问题：重启卡在 initramfs 挂载根目录。因为 balance 后 chunk root / tree root 被分发到了 devid 2，导致只解密主盘时 Btrfs 无法 Mount（报 failed to read chunk root），btrfs restore 也因缺盘无法解析文件树。出现“挂载 Btrfs 需解锁盘2，解锁盘2 需 Keyfile，Keyfile 存在 Btrfs 里”的死锁。环境：Arch Linux + LUKS2 + Btrfs
背景：主盘 cryptroot，新盘 cryptroot2（使用主盘 /etc/cryptsetup-keys.d/nvme1.key 加密）。btrfs device add 后执行了 btrfs balance，随后重启。
问题：重启卡在 initramfs 挂载根目录。因为 balance 后 chunk root / tree root 被分发到了 devid 2，导致只解密主盘时 Btrfs 无法 Mount（报 failed to read chunk root），btrfs restore 也因缺盘无法解析文件树。出现“挂载 Btrfs 需解锁盘2，解锁盘2 需 Keyfile，Keyfile 存在 Btrfs 里”的死锁。
以上是我和Gemini以及chatgpt的对话记录
我知道这一且错误都是由于我自大、愚蠢、过于轻信LLM导致的，但现在我只想请求
社区的帮助，是否还有其他路径有机会恢复我的数据，感谢
依云
(lilydjwg)
2
（整段整段的粗体字难看死了，帮你处理了。）
简单来说，你的数据死掉啦。你把你的btrfs切成了两块，其中一块需要存于其自身的文件来解锁，这就打了个死结。
虽然理论上来说，如果你足够幸运的话（大约50%概率？），你的密钥文件位于还能解密的部分的话，你是可以找到那个key并用它来解锁另一块的。但是，你有能力在茫茫数据的汪洋里找到你的key吗？
另外，无论你打算如何解密，我都建议你添加一个可以解密的密码——这个密码你最好写在纸上然后找个安全的地方放着。
Qine
3
感谢帮助。
现在的我只能相信过去的我把必要的数据都做好备份了吧
明天再尝试一下例如btrfs metadata之类的路径有没有可能行得通，目前确认nvme1n1p1只有密钥文件一个解锁方式，没有手动添加其他密钥。
我还有备用的Windows系统可以用于临时处理必须事务。
如果有什么折腾出事反面教材收集的话，可以把我挂上去，我也计划乘此机会好好反思一下过度依赖LLM的问题，以及评估我所面对的威胁模型、硬件软件时间精力平衡之下究竟应该选择怎样的方案，而不是盲目跟风红线蹦迪，一切以稳定性为最优先，不要过于偏执、仅依赖LLM尝试自己没有完全掌握的技术。
依云
(lilydjwg)
4
另外帮你算了一下，如果你的已解密硬盘有1TiB大，而密钥文件是4KiB的话，你可以尝试把每一个4KiB的数据当成密钥去尝试解密——有大概率你这4KiB数据没有被打散。假设你每秒能尝试10次解密的话（对个人来说这已经相当快了），这样试下来只需要：
>>> 1 TiB / 4 KiB / (10 / s) -> d
(1 tebibyte / 4 kibibyte) / (10 / second) ➞ day
= 310.689 day [Time]
也就是不到一年的时间。
LLM 对话太长我没看，gemini 点“继续此对话”一直卡加载，想总结都总结不成。
单看一楼的描述，这里的关键在于你依赖了一个本身就不稳定的操作：在多设备 btrfs 的多个设备尚未全部就绪（解锁）时就挂载，并且还把唯一能解锁其余设备的密钥存放在此文件系统上。正常来说在多设备文件系统的设备没有全部就绪时就不应该挂载，强行挂载的话属于 degraded，一般是设备不可用时救急的操作。只要你依赖了这个，即使没有按 LLM 建议 balance，也迟早会在某次 balance 或者什么别的操作时触发问题。
对于 argon2id 来说似乎不太现实，要慢得多（
pharra
7
作为个人用户，硬盘加密/Raid，当你没有数据安全问题时，这两个可能就是你数据安全问题的来源 