在法國用 Freebox 跑 NFS 給 Raspberry Pi 當備份碟，同步卡住的實測

Freebox Pop 韌體 4.8.x，光纖 1Gbps/700Mbps，Raspberry Pi 4B 4GB 跑 Raspberry Pi OS Bookworm（核心 6.6），USB 3.0 外接一顆 2TB SSD 接到 Freebox 的 USB 埠，透過 NFS 掛到 Pi 上，用來接收每日備份。資料量約 180GB、二十多萬個小檔案，單檔平均 1MB 上下。現象是 rsync 跑十幾分鐘後整臺卡住，df -h 顯示掛載點還在，但 ls 進目錄沒有回應，dmesg 會出現 nfs: server 192.168.1.254 not responding, still trying，等一段時間又自己恢復。

我先排除網路。Pi 用有線接在同一臺 Freebox 後面，ping 延遲穩定在 0.3ms，iperf3 跑得出 900Mbps 以上，所以不是鏈路問題。於是我把 NFS 掛載參數改得保守一點：

192.168.1.254:/mnt/ssd/backup /mnt/backup nfs4 rw,soft,timeo=100,retrans=3,rsize=32768,wsize=32768,noatime,nofail,x-systemd.automount 0 0

關鍵是 soft 加短 timeo，讓掛載點在對方沒回應時會回錯誤而不是無限等待，rsize/wsize 從預設的 1MB 降到 32KB。同步指令也改成一批一批來：

rsync -a --delete --exclude='*.tmp' --bwlimit=20M /home/pi/data/ /mnt/backup/

這樣跑完整晚沒有再卡死。代價是吞吐掉到 15–20MB/s，180GB 要跑兩三個小時，但至少不會整個 shell 卡住。

為什麼會這樣：Freebox 的 NFS 服務本質上是韌體裡的一個輕量實作，不是完整的 Linux NFS server，對大量小檔案的 metadata 操作和併發請求處理得不好，佇列一滿就開始丟回應。Pi 這邊預設是 hard 掛載，對方不回應就會一直重試，於是整個行程卡在不可中斷的狀態。把掛載改成 soft、把讀寫塊縮小，等於降低同時壓在 Freebox 上的請求數，让它有機會消化。

會失效的地方：soft 掛載在寫入時遇到逾時會直接回 EIO，rsync 會把那個檔案當成失敗，所以一定要用 --delete 之外的檢查，例如事後對 rsync -n 的輸出或跑一次校驗。另外這個做法不適合放資料庫檔案或任何需要嚴格寫入順序的東西；我也試過把 rsize 拉到 128KB，短時間看起來快，但十幾分鐘後又開始 not responding。還有，Freebox 重開機後 NFS 共享有時不會自動回來，x-systemd.automount 可以救，但第一次存取會多等幾秒。

你們在法國用 Freebox 內建的 USB 共享跑 NFS 或 SMB 時，是直接接受它的吞吐，還是會在中間再放一臺機器做快取？我想知道有沒有人試過把 NFS 換成 SMB 之後小檔案同步反而比較穩。