F2FS が HC620 SMR HDD を固まらせる？Linux SMR ディスクのトラブルシュート

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

HC620 のようなヘリウム封入 SMR HDD を F2FS と組み合わせたとき、システムが固まる、アプリが応答しない、iowait が長時間高い、といった症状が出る場合、原因は一つの設定ミスではないことが多い。デバイス特性とファイルシステムの方針が衝突している。

Western Digital Ultrastar DC HC620 は Host-managed SMR である。順次書き込み、zoned を意識したワークロード、底層制約を理解したソフトウェアスタックに向いている。一方 F2FS はフラッシュストレージ向けに設計されたログ構造ファイルシステムだ。多くのランダム書き込みを順次書き込みに寄せられるが、空き容量が少ない、GC が頻繁、metadata 更新が多いと、機械式 SMR HDD を長い内部整理周期へ引きずり込むことがある。

まずこの問題か確認する

最初に次を確認する。

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 と見てよい。

次に、HDD が zoned device として見えているか確認する。

1
2

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

Host-managed SMR であれば、通常のファイルシステムや通常のランダム書き込み負荷では性能が大きく落ちる可能性がある。一般的な drive-managed SMR のように、複雑さを HDD firmware が完全に隠してくれるわけではなく、ホスト側ソフトウェアが書き込み規則を理解する必要がある。

F2FS が停止を増幅しやすい理由

SMR の問題は、任意の場所を自由に上書きできない点にある。容量を増やすために隣接トラックを重ねるため、ランダム書き込みや頻繁な上書き、キャッシュ枯渇が起きると、追加のデータ移動と整理が必要になる。

F2FS はもともと NAND flash 向けだ。ログ構造書き込みを使い、segment cleaning と garbage collection で空間を回収する。この設計は SSD では自然だが、機械式 HDD、特に SMR HDD では、GC による読み書きの移動が大きな tail latency になる。

F2FS の background GC、foreground write、checkpoint、metadata 更新、HDD 自身の SMR cleanup が重なると、I/O キューが長時間埋まり続ける。ユーザーから見ると、ファイルコピー、ディレクトリ削除、ダウンロード、展開、データベース書き込みでシステム全体が固まったように見える。

まず保守的な mount option から調整する

すぐにファイルシステムを移行できない場合は、/etc/fstab の mount option から調整する。

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

各 option の意味は次の通り。

nodiscard：リアルタイム discard を無効にする。機械式 HDD は SSD のように頻繁な TRIM/discard を必要としないことが多い。
active_logs=2：F2FS は 2、4、6 個の active logs をサポートし、既定は通常 6。2 に下げると、同時ログによる seek 圧力を減らせる。
gc_merge：background GC thread に一部の foreground GC request を処理させ、プロセスが遅い GC を直接踏んだときの停止を軽減する。
flush_merge：cache flush request をまとめる。下位デバイスの flush が遅い場合に有効なことがある。
lazytime：一部のアクセス時刻更新による metadata 書き込みを減らす。

checkpoint=disable を通常の性能改善策として使うのは勧めない。checkpoint の負荷は減る可能性があるが、異常終了や停電時のリスクが高くなる。kernel documentation でも、checkpoint を無効にしている間も空き領域を確保するために GC が必要だと説明されている。代償を理解していないなら、長期運用の性能スイッチとして使うべきではない。

I/O scheduler を調整する

機械式 HDD と SMR HDD では、request merge と遅延制御が重要になりやすい。まず現在の scheduler を確認する。

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

mq-deadline への切り替えを試せる。

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

デスクトップ用途なら bfq も試す価値がある。順次スループットだけで判断せず、停止が減るか、await が下がるか、操作感が安定するかを見る。

F2FS の background GC を制限する

F2FS の sysfs path は実際のデバイス名に依存する。まず確認する。

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

対応する mount device に対して GC interval を調整する。

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 を増やすと background GC が I/O を奪う頻度は下がるが、空間回収は遅くなる。ディスクが満杯に近いほど foreground GC が再び発生しやすいため、十分な空き容量を残す必要がある。

長期的には別の選択がよい

重要データを保存しているなら、最も安定した方針はバックアップ後にファイルシステムを変えるか、より適した HDD に変えることだ。

大容量の機械式 HDD では、次を優先して検討する。

XFS：大きなファイル、バックアップ、メディアライブラリ、アーカイブ、順次書き込み負荷に向く。
EXT4：互換性が高く、挙動が安定し、トラブルシュート資料も多い。

Host-managed SMR の場合は、kernel、controller、filesystem、application stack が zoned block device の使い方を本当にサポートしているかも確認する。そうでなければ、普通のランダム書き込み HDD として扱ったときに、予測しにくい長時間停止が起きやすい。

実用的な勧め

この種の HDD は、cold data、アーカイブ、バックアップ、メディアファイル、順次書き込みに向いている。download cache、container image、VM disk、database、頻繁な展開、小ファイルのランダム書き込みには向かない。

どうしても F2FS を使い続けるなら、少なくとも次を行う。

リアルタイム discard を無効にする。
active_logs=2 で同時ログを減らす。
gc_merge と flush_merge を有効にする。
十分な空き容量を残し、満杯に近づけない。
download directory、database、VM image をこのディスクに置かない。
平均速度だけでなく iostat -x 1 を定期的に見る。

まとめると、HC620 + F2FS の停止は、SMR の書き込み制約、F2FS GC、機械式 HDD の tail latency が重なった結果である。短期対策は mount option、scheduler、background GC の調整。長期対策は XFS/EXT4 への移行、または SMR HDD を本来向いている順次書き込みアーカイブ用途に戻すことだ。

参考リンク：

SMR HDD on KnightLiブログ