處理 BTRFS ref/backpointer 不匹配，缺少 backref

btrfs receive由於缺少擴展，btrfs 文件系統在操作過程中報告了一些錯誤。從日誌：

BTRFS error (device dm-1): unable to find ref byte nr 190303420416 \
     parent 0 root 594  owner 1 offset 0
BTRFS: error (device dm-1) in __btrfs_free_extent:6944: errno=-2 No such entry
BTRFS info (device dm-1): forced readonly
BTRFS: error (device dm-1) in btrfs_run_delayed_refs:2956: errno=-2 No such entry

A btrfs scrub（在 umount + mount 之後）失敗並出現類似錯誤。

Abtrfs check報告 3 個擴展的問題 - 每個擴展問題的報告如下：

checking extents
ref mismatch on [190303420416 16384] extent item 0, found 1
Backref 190303420416 parent 594 root 594 not found in extent tree
backpointer mismatch on [190303420416 16384]
owner ref check failed [190303420416 16384]

我的問題是：如何將這些數字轉化為有用的東西？例如檢查某些文件/目錄是否受到影響？

以及如何處理此類錯誤？

Abtrfs check --repair似乎工作沒有嚴重抱怨：

 ref mismatch on [190303420416 16384] extent item 0, found 1
* repair deleting extent record: key 190303420416 169 1
* adding new tree backref on start 190303420416 len 16384 parent 0 root 594
 Backref 190303420416 parent 594 root 594 not found in extent tree
 backpointer mismatch on [190303420416 16384]
 owner ref check failed [190303420416 16384]

（*標記是我的）

這是否意味著修復成功而沒有失去任何數據？

成功的btrfs check --repair命令不一定會產生一致的 btrfs 文件系統。

在一種情況下，我觀察到 a btrfs scrubafter btrfs check觸發WARN_ON()了fs/btrfs/extent-tree.c. 並且接收快照會導致 IO 失敗（這會強制重新掛載只讀）。

因此，由於 a btrfs check，後跟 abtrfs check --repair和 a的執行時間btrfs scrub可能非常重要——並且這些操作具有不確定的結果：一個實際的替代方法是重新創建 btrfs 文件系統並恢復備份。

2021-12-14 跟進： FWIW，這些錯誤是由故障/低質量 USB 集線器（供應商字元串：‘Genesys Logic, Inc.’）引起的。直接連接USB磁碟驅動器後，這些錯誤再也沒有出現過。在此之前，每天將快照發送到外部 USB 驅動器時，每隔幾個月左右就會出現此類錯誤。我什至嘗試了另一個 Genesys USB Hub（雖然標籤不同），但它產生了類似的錯誤模式。

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