RAID1 上的 btrfs 替換速度非常慢，存在故障磁碟

我正在嘗試替換 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 試圖將會計數據寫入磁碟（即使它完全空閒）。

即使是 mount ro， btrfs 也可能會嘗試寫入磁碟。掛載選項-onologreplay：

        Warning
           currently, the tree log is replayed even with a read-only
           mount! To disable that behaviour, mount also with nologreplay.

我怎樣才能加快這個過程？

這篇文章說replace重啟後會繼續。

我在想：

1. 取消目前replace
2. 移除故障磁碟
3. mount -o degraded,rw

• 鑑於這種一次性安裝選項的問題，希望沒有停電）

在這個時間點，我建議同時：

1. 允許replace在不存在故障磁碟的情況下繼續（最近scrub顯示好磁碟具有所有數據）
2. 轉換數據以single允許rw在過程中斷電的情況下再次安裝

這是一個replace提前完成的合理計劃嗎？

我的計算表明，考慮到磁碟 I/O 速度，6.5 小時（而不是 10 天）是可行的。

鑑於replace正在爬行，我做了以下事情：

1. 確保降級的文件系統noauto在/etc/fstab
2. 重新啟動機器（由於 I/O 掛起大約需要 20 分鐘）
3. 在故障驅動器上禁用包含 btrfs fs 的 LVM VG：

sudo vgchange -an <failed-vg>

4. 禁用故障設備：

echo 1 | sudo tee /sys/block/sdb/device/delete

5. 掛載文件系統-o ro,degraded（degraded只能使用一次）
6. 檢查replace status並看到它被暫停：

Started on 26.Jan 00:36:12, suspended on 26.Jan 10:13:30 at 4.1%, 0 write errs, 0 

7. 安裝-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,DUPand Metadata,single，而不僅僅是RAID1，所以我重新平衡了：

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

resize此外，如果兩個設備現在都包含 slack ，請考慮ing：

btrfs filesystem resize max /mountpoint

我還建議您scrub，因為我有262016 個csum似乎與中斷有關的可糾正錯誤replace。

這個答案提到了對故障磁碟的寫入導致replace停止。

它建議dmsetup在故障磁碟上設置一個 COW 設備，以便任何寫入都成功。

注意：在這種情況下，文件系統包含在dmcrypt設備中。如果不是這種情況，請參閱我關於“陷阱”和潛在數據失去的評論。

引用自：https://unix.stackexchange.com/questions/496777