我正在尝试更换 RAID1 btrfs 文件系统中出现故障的磁盘。
我仍然可以挂载该分区rw（大约 5 分钟的延迟和大量 I/O 内核错误之后）。
我首先replace尝试-r让故障磁盘不影响操作速度：
-r only read from <srcdev> if no other zero-defect mirror exists. (enable this if your drive has lots of read errors, the access would be very slow)
尽管如此，我的表现还是很差。分区大小为3.6TiB，9.25小时后我得到：
3.8% done, 0 write errs, 0 uncorr. read errs
按照这个速度，需要10多天才能完成！
由于情况超出了我的控制范围，所以等待的时间太长了。
我经常看到有关故障磁盘的内核错误，平均每 5 分钟左右出现一次：
Jan 26 09:31:53 tara kernel: print_req_error: I/O error, dev sdc, sector 68044920
Jan 26 09:31:53 tara kernel: BTRFS warning (device dm-3): lost page write due to IO error on /dev/mapper/vg4TBd2-ark
Jan 26 09:31:53 tara kernel: BTRFS error (device dm-3): bdev /dev/mapper/vg4TBd2-ark errs: wr 8396, rd 3024, flush 58, corrupt 0, gen 3
Jan 26 09:31:53 tara kernel: BTRFS error (device dm-3): error writing primary super block to device 2
Jan 26 09:32:32 tara kernel: sd 2:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jan 26 09:32:32 tara kernel: sd 2:0:0:0: [sdc] tag#0 Sense Key : Medium Error [current]
Jan 26 09:32:32 tara kernel: sd 2:0:0:0: [sdc] tag#0 Add. Sense: Unrecovered read error
Jan 26 09:32:32 tara kernel: sd 2:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 02 eb 9e 23 00 00 04 00
Jan 26 09:32:32 tara kernel: print_req_error: critical medium error, dev sdc, sector 391967000
我猜测这些错误是由于 btrfs 尝试将会计数据写入磁盘（即使它完全空闲）造成的。
即使已安装ro，btrfs 也可能会尝试写入磁盘。安装选项-onologreplay:
Warning currently, the tree log is replayed even with a read-only mount! To disable that behaviour, mount also with nologreplay.
我怎样才能加快这个过程？
本文表示 areplace将在重新启动后继续。
我在想：
- 取消当前
replace - 删除故障磁盘
mount -o degraded,rw- 希望不会出现停电的情况这个一次性安装选项的陷阱）
此时此刻，我建议同时：
- 允许
replace在不存在故障磁盘的情况下继续（最近scrub显示好磁盘具有所有数据） - 将数据转换为
single允许rw在过程中断电时再次安装
这是一个尽早完成的合理计划吗replace？
我的计算表明，考虑到磁盘 I/O 速度，6.5 小时（而不是 10 天）是可行的。
答案1
在这种特殊情况下，您看到的 5 分钟等待是内核尝试访问故障磁盘上的数据。在大多数情况下，这是故意的，因为它增加了恢复完整数据的机会。最有可能的是 btrfs是跳过损坏的数据，但内核在放弃之前仍尝试访问损坏的驱动器一段时间。根据：https://superuser.com/questions/905811/faster-recovery-from-a-disk-with-bad-sectors 您可以使用TLER限制以使内核更快地跳过错误。
要检查默认值：
# smartctl -l scterc /dev/sda
将写入和读取时间均设置为 5 秒：
# smartctl -l scterc,50,50 /dev/sda
请注意，禁用意味着等待恢复的时间不受限制，这可以减少从磁盘恢复的数据量。
答案2
如果您在故障驱动器上有重要数据，那么您需要的程序是ddrescue.
首先，复制重要的内容
如果文件系统上有任何您长时间离不开的数据，那么首先执行此操作。
断开故障驱动器的连接。
将文件系统安装为只读和降级。
sudo mount -o degraded,ro /dev/sdX /mount/dir将您需要的数据复制到另一个位置。
然后解救驱动器
现在，为了获取其余的数据，我们使用 创建驱动器的映像ddrescue。
卸载 Btrfs 文件系统。不要安装它。不要将其安装为只读。
拥有一个格式化为 Ext4 或 Btrfs 并禁用写入时复制的新驱动器。
运行 ddrescue，将坏掉的驱动器上的映像创建到新驱动器上
sudo ddrescue /dev/sdX /path/to/save.img /path/to/save.mapDdrescue 可能需要数小时甚至数天才能完成，具体取决于驱动器大小和速度。此外，如果驱动器故障太多，它可能永远无法完成。你允许它救援的时间取决于你。
当 ddrescue 完成处理后，删除/断开故障驱动器，并且不要再次重新连接。
将驱动器映像安装到循环设备。
sudo losetup -Pf --show /path/to/save.img现在您应该能够使用正常的挂载命令而不是降级模式挂载 Btrfs raid 文件系统。它将自动使用循环图像设备来代替丢失的驱动器。
安装 Btrfs 驱动器后，立即对其运行清理以修复 ddrescue 可能无法恢复的任何数据。
从那里你有两个选择。您可以继续使用循环设备运行 Btrfs 文件系统，也可以使用另一个驱动器替换循环设备。
答案3
这个答案提到写入故障磁盘会导致系统replace停止运行。
它建议dmsetup在故障磁盘上设置 COW 设备，以便任何写入都能成功。
警告：在这种情况下，文件系统被封装在dmcrypt设备内。如果情况并非如此，请参阅我关于“陷阱”和潜在数据丢失的评论。
答案4
鉴于正在replace爬行，我执行了以下操作：
- 确保降级的文件系统
noauto位于/etc/fstab - 重新启动机器（由于 I/O 挂起，大约需要 20 分钟）
禁用故障驱动器上包含 btrfs fs 的 LVM VG：
sudo vgchange -an <failed-vg>禁用发生故障的设备：
echo 1 | sudo tee /sys/block/sdb/device/delete挂载文件系统
-o ro,degraded（degraded只能使用一次）检查了一下
replace status，发现已经暂停了：Started on 26.Jan 00:36:12, suspended on 26.Jan 10:13:30 at 4.1%, 0 write errs, 0安装
-o remount,rw并看到replace继续：kernel: BTRFS info (device dm-5): continuing dev_replace from <missing disk> (devid 2) to target /dev/mapper/vg6TBd1-ark @4%
当我写这篇文章时：
replace status每 30 秒左右显示 0.1% 的健康进展iostat -d 1 -m <target-dev>显示约为 145MB/s（希捷宣传为 160MB/s）
更新：
完成后，我注意到btrfs device usage /mountpoint显示了一些Data,DUP和Metadata,single，而不是仅RAID1，所以我重新平衡：
btrfs balance start -dconvert=raid1,soft -mconvert=raid1,soft /mountpoint
另外，resize如果两个设备现在都包含松弛，请考虑 ing：
btrfs filesystem resize max /mountpoint
我也会scrub像我一样推荐你262016 个可纠正的csum错误似乎与中断有关replace。