bupt.moe
tg5.3 тыс. подписчиков
Открыть пост ↗
#btrfs
群友悲剧之 degraded rw + device replace 差点酿成惨剧
有一天，某个小可爱想把自己的 btrfs RAID10 卷从两个未加密硬盘换成加密硬盘。由于没有第三块硬盘用来倒腾，所以他想到了一个绝妙的主意（下文用devA devB表示两块硬盘）：
1.
2. 将 devB 以 degraded,rw 选项加载，开始
3. replace完成之后， 卸载 btrfs 并且
4. 将已经完成加密的 dev A 也以
然而当他完成第三步，正打算进行第四步时，发现没法加载 btrfs 了！，提示
因为根据 btrfs 手册所述 ，在 degraded mount 下，如果有新的 chunk 分配，而且现在的硬件情况不能满足当前 profile 要求的时候，会降级到其他 profile （比如 SINGLE），同时手册也建议在 degraded,rw mount之后进行 balance 来避免此类情况。这种行为虽然在手册里写明了，但是还是比较反直觉的。
所以在此类情况下，第二步的replace时以 SINGLE profile 写入了一些信息到 devB，从而第四步的时候找不到chunk root导致挂载失败。
但是幸运的是，luksFormat并不会覆盖数据区域，只会改写LUKS头，而 btrfs 一般从 64KiB 开始写，并不会互相覆盖。所以 devB 还保留着完整的 btrfs 数据，我们的小可爱完整地找回了他的数据。
编者注：还以为是硬件不可靠查了半天试图恢复，只能说自己还是学艺不精。
群友悲剧之 degraded rw + device replace 差点酿成惨剧
有一天，某个小可爱想把自己的 btrfs RAID10 卷从两个未加密硬盘换成加密硬盘。由于没有第三块硬盘用来倒腾，所以他想到了一个绝妙的主意（下文用devA devB表示两块硬盘）：
1.
luksFormat devA2. 将 devB 以 degraded,rw 选项加载，开始
btrfs device replace 把设置好的加密 devA 替换原有的未加密devA3. replace完成之后， 卸载 btrfs 并且
luksFormat devB4. 将已经完成加密的 dev A 也以
degraded,rw 加载，然后 replace 掉 devB然而当他完成第三步，正打算进行第四步时，发现没法加载 btrfs 了！，提示
BTRFS error (device devB): failed to read chunk root 这是为什么呢？RAID1 的卷即使丢了一个设备也应该可以找到另外一个啊？因为根据 btrfs 手册所述 ，在 degraded mount 下，如果有新的 chunk 分配，而且现在的硬件情况不能满足当前 profile 要求的时候，会降级到其他 profile （比如 SINGLE），同时手册也建议在 degraded,rw mount之后进行 balance 来避免此类情况。这种行为虽然在手册里写明了，但是还是比较反直觉的。
所以在此类情况下，第二步的replace时以 SINGLE profile 写入了一些信息到 devB，从而第四步的时候找不到chunk root导致挂载失败。
但是幸运的是，luksFormat并不会覆盖数据区域，只会改写LUKS头，而 btrfs 一般从 64KiB 开始写，并不会互相覆盖。所以 devB 还保留着完整的 btrfs 数据，我们的小可爱完整地找回了他的数据。
编者注：还以为是硬件不可靠查了半天试图恢复，只能说自己还是学艺不精。
Новый список