F2FS 導致 HC620 疊瓦碟卡死？Linux SMR 硬碟排障指南

Fri, 08 May 2026 22:34:39 +0800

HC620 這類氦氣封裝疊瓦碟配合 F2FS 使用時，如果出現系統卡住、應用程式無回應、iowait 長時間飆高，通常不是單一參數沒調好，而是裝置特性和檔案系統策略撞在了一起。

Western Digital Ultrastar DC HC620 屬於 Host-managed SMR。它更適合順序寫、分區化寫入和明確知道底層約束的軟體棧。F2FS 則是為快閃記憶體設計的日誌結構檔案系統，雖然能把很多隨機寫組織成順序寫，但在空間緊張、垃圾回收頻繁或 metadata 更新密集時，仍然可能把機械疊瓦碟拖進很長的內部整理週期。

先確認是不是這類問題

建議先看三個現象：

1
2
3

iostat -x 1
iotop -oPa
dmesg -T | grep -Ei "f2fs|blk|zoned|reset|timeout|I/O error"

如果能看到磁碟 %util 長時間接近 100%，await 很高，系統裡大量行程卡在 D 狀態，基本可以判斷瓶頸在區塊裝置 I/O。

再確認硬碟是否以 zoned 裝置暴露：

1
2

lsblk -o NAME,MODEL,SIZE,ROTA,ZONED,SCHED,MOUNTPOINTS
cat /sys/block/sdX/queue/zoned

如果是 Host-managed SMR，普通檔案系統和普通隨機寫負載都可能表現很差。它不像常見的桌面 SMR 碟那樣完全由硬碟韌體隱藏複雜度，而是更依賴主機端軟體理解寫入規則。

為什麼 F2FS 容易把卡頓放大

SMR 的問題在於寫入不是任意覆蓋那麼簡單。疊瓦磁軌為了提高容量，會讓相鄰磁軌部分重疊；當寫入模式偏隨機、覆蓋頻繁或快取耗盡時，硬碟需要做額外的資料搬運和整理。

F2FS 的問題在於它本來面向 NAND flash。它採用日誌結構寫入，並透過 segment cleaning 和 garbage collection 回收空間。這個設計在 SSD 上通常很自然，因為 SSD 沒有機械尋道；但在機械硬碟上，尤其是 SMR 碟上，GC 產生的讀寫搬運可能變成明顯的長尾延遲。

當 F2FS 後台 GC、前台寫入、checkpoint、metadata 更新和硬碟自身的 SMR 整理疊在一起時，I/O 佇列會被持續占滿。表現到使用者層，就是複製檔案、刪除目錄、跑下載、解壓縮或資料庫寫入時系統像「凍住」一樣。

掛載參數先這樣保守調整

如果暫時不能遷移檔案系統，可以先從 /etc/fstab 的掛載參數下手：

`1`	`UUID=xxxx /data f2fs defaults,nodiscard,active_logs=2,gc_merge,flush_merge,lazytime 0 0`

幾個參數的含義：

nodiscard：關閉即時 discard。機械硬碟通常不需要像 SSD 那樣頻繁發送 TRIM/discard，保守關閉更穩。
active_logs=2：F2FS 支援 2、4、6 個 active logs，預設通常是 6。降到 2 可以減少日誌並發帶來的尋道壓力。
gc_merge：讓後台 GC 執行緒處理部分前台 GC 請求，降低前台行程直接觸發慢 GC 時的卡頓。
flush_merge：合併 cache flush 請求，底層裝置處理 flush 很慢時可能有幫助。
lazytime：減少部分存取時間更新帶來的 metadata 寫入。

checkpoint=disable 不建議作為常規方案。它確實可能減少 checkpoint 壓力，但在異常斷電或崩潰後風險更高，而且內核文件也提醒，停用 checkpoint 後檔案系統仍需要 GC 來確保可用空間。除非你非常清楚代價，否則不要把它當成「效能開關」長期使用。

調整 I/O 調度器

機械碟和 SMR 碟通常更需要請求合併與延遲控制。可以先查看目前調度器：

`1`	`cat /sys/block/sdX/queue/scheduler`

可嘗試切換到 mq-deadline：

`1`	`echo mq-deadline \| sudo tee /sys/block/sdX/queue/scheduler`

如果系統用於桌面互動，也可以測試 bfq。不要只看順序吞吐，重點觀察卡頓是否減少、await 是否下降、互動是否更穩定。

限制 F2FS 後台 GC

F2FS 的 sysfs 路徑以實際裝置名為準，先確認：

`1`	`ls /sys/fs/f2fs/`

然後針對對應掛載裝置調整 GC 間隔，例如：

1
2

echo 60000 | sudo tee /sys/fs/f2fs/sdX/gc_min_sleep_time
echo 120000 | sudo tee /sys/fs/f2fs/sdX/gc_max_sleep_time

這裡的 sdX 只是示例，實際可能是 sda1、dm-0 或其他名稱。調大 GC sleep time 的作用是降低後台 GC 搶占 I/O 的頻率，但代價是空間回收更慢。磁碟空間越接近滿碟，越容易再次觸發前台 GC，所以還要留出足夠空閒空間。

更推薦的長期方案

如果這塊碟存重要資料，最穩妥的方案是備份後換檔案系統，或者換更適合的硬碟。

對大容量機械硬碟，優先考慮：

XFS：適合大檔案、備份碟、媒體庫、歸檔和順序寫負載。
EXT4：相容性強，行為穩定，排障資料多。

如果是 Host-managed SMR，還要確認你的內核、控制器、檔案系統和應用是否真正支援 zoned block device 的使用方式。否則，把它當成普通隨機寫硬碟用，很容易遇到不可預測的長時間卡頓。

實用建議

這類碟更適合冷資料、歸檔、備份、媒體檔案和順序寫入，不適合下載快取、容器映像、虛擬機磁碟、資料庫、頻繁解壓縮目錄或小檔案隨機寫。

如果必須繼續用 F2FS，建議至少做到：

關閉即時 discard。
active_logs=2，減少並發日誌。
開啟 gc_merge 和 flush_merge。
保持較高空閒空間，不要接近滿碟。
避免把下載目錄、資料庫、虛擬機映像放在這塊碟上。
定期觀察 iostat -x 1，不要只看平均速度。

總結一下：HC620 + F2FS 卡死，本質上是 SMR 寫入約束、F2FS GC 和機械碟長尾延遲疊加後的結果。臨時方案是調掛載參數、調調度器、限制後台 GC；長期方案是遷移到 XFS/EXT4，或者把這類 SMR 碟放回更適合它的順序寫歸檔場景。

參考連結：

SMR硬碟 on KnightLi的博客