☰

我可以在 btrfs 替换期间重新启动然后恢复它吗？

tag-icon • tag-icon btrfs replace
我可以在 btrfs 替换期间重新启动然后恢复它吗？

我的硬盘已损坏并出现很多读取错误。我目前正在进行 btrfs 替换，但 24 小时后完成率刚刚超过 5%，这是一个问题：这是我的工作计算机；这是我的工作计算机；我目前已启动到 Live USB，但我需要返回到现有的 Ubuntu 才能继续我的工作（由于所有读取错误，启动非常困难，但有时能够成功）。

注意：整个硬盘，或者至少是它的这个分区，当前的读取速度约为 500 KBps，即使没有读取错误 -btrfs replace status当前报告 0 个读取错误。

所以我有两个选择：1）关闭，重新启动到其他操作系统，然后尝试运行btrfs replace start我第一次运行的相同命令。 2）取消当前的替换操作，这可能需要很长时间（我之前已经尝试过取消，替换一分钟后，似乎需要很长时间才能取消）并且会撤销一天来之不易的传输进度。 3) 承认失败，在接下来的 2-3 周内适应这个 LiveUSB 操作系统，并祈祷清洁人员不要碰撞 U 盘。

答案1

重新提出这个问题是因为它是搜索“btrfs 替换简历”时 Google 的最高结果，而现有答案并不能说明全部情况。

重新启动后，替换过程会自动恢复（很像天平）。我什至不得不在替换操作期间进行硬重置，并且在重新启动并重新安装文件系统后，该过程愉快地继续。所以我的猜测是，并不是中断的替换操作本身给 sssheridan 带来了所有这些问题，而是必须从死掉的硬盘启动的情况。

中断替换后安装时，会打印如下日志行：

BTRFS info (device sdh1): continuing dev_replace from /dev/sdb1 (devid 5) to target /dev/sdh1 @95%

最后一个数字是完成百分比。

答案2

回答我的问题：我试过了，一切都着火了。输入/输出错误无处不在，不知何故我的文件系统认为它是 RAID1，但实际上不是。公平地说，分区已经损坏，这似乎是问题的一部分，但尽管如此，我不建议这样做。做一个btrfs replace cancel并等待它结束。

答案3

长话短说：

是的。但scrub之后就跑了。

长版本：

这篇 LWN 文章给出提交文本replace并表示：

在操作过程中崩溃或断电是安全的，该过程会在下一次安装时恢复。

我在replace完成大约 5% 时重新启动，因为由于存在故障磁盘，RAID1 上的 btrfs 替换速度非常慢。

恢复并完成后replace，我注意到btrfs device usage /mountpoint显示了一些Data,DUP和Metadata,single，而不是仅显示RAID1。这可能是由于btrfs写入所致DUP，因为它无法将第二个副本写入故障驱动器。我重新平衡以将所有内容设为 RAID1：

btrfs balance start -dconvert=raid1,soft -mconvert=raid1,soft /mountpoint

现在所有数据都显示为RAID1，我想我只需检查一切是否正常：

btrfs scrub start -Bd /mountpoint

我很高兴我这么做了，因为我在（新更换的设备）上擦洗了很多csum errors大约 151GiB 的内容：id 2

scrub device /dev/mapper/vg4TBd3-ark (id 1) status
        scrub started at Mon Jan 28 20:47:33 2019, running for 00:41:40
        total bytes scrubbed: 153.53GiB with 0 errors
scrub device /dev/mapper/vg6TBd1-ark (id 2) status
        scrub started at Mon Jan 28 20:47:33 2019, running for 00:41:40
        total bytes scrubbed: 151.49GiB with 174840 errors
        error details: csum=174840
        corrected errors: 174837, uncorrectable errors: 0, unverified errors: 0

scrub此时正在爬行。日志显示了许多行，例如：

BTRFS warning (device dm-5): checksum error at logical 3425803567104 on dev /dev/mapper/vg6TBd1-ark, physical 162136981504, root 5, inode 3367374, offset 0, length 4096, links 1 (path: HDDs/Quantum LM30/Linux1/home/tn/uts.old/etc/root/home/tn/build/linux-2.4.13-ac8/linux/include/net/sock.h)
BTRFS error (device dm-5): bdev /dev/mapper/vg6TBd1-ark errs: wr 0, rd 0, flush 0, corrupt 1, gen 0                                                                               
BTRFS error (device dm-5): fixed up error at logical 3425803567104 on dev /dev/mapper/vg6TBd1-ark                                                                                 
scrub_handle_errored_block: 806 callbacks suppressed

当我下次检查 184GiB 擦洗时，我最终得到了总共 262016 个已纠正的错误（此时它再次愉快地缩放）。

此后我没有收到任何错误，这意味着所有错误都集中在 151GiB 点附近。

151GiB 大约占我重新启动时 2.88TiB 总量的 5%。

也许这只是巧合，但我很高兴我scrub无论如何都跑了。

相关内容