HC620 on KnightLiブログ

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 を本来向いている順次書き込みアーカイブ用途に戻すことだ。

参考リンク：

HDD 高騰時代、NAS が満杯でもまだ増設しない：200 元 TerraMaster + HC620 のコールドデータ構成

Mon, 04 May 2026 11:46:53 +0800

HDD 価格が大きく上がっている時期に NAS の容量がいっぱいになっても、すぐにディスクを増設する必要はありません。メイン NAS が正常に動いていて、単に容量が足りなくなってきただけなら、まずデータをアクセス頻度で分けるほうが現実的です。よく使うホットデータは元の NAS に残し、あまり使わないコールドデータとバックアップは別のコールドストレージ用ディスクへ移します。

この記事は低コストな構成の記録です。大容量の HC620 をコールドデータ保存用に使い、安価な TerraMaster F2-220、F2-221、または F4 をコピーとマウント用ノードとして使います。高性能を狙う構成ではありません。今は HDD を更新しにくい時期なので、まずメイン NAS の空き容量を確保するのが目的です。

考え方

まずデータをアクセス頻度で分けます。

ホットデータ：写真、作業資料、最近のダウンロード、よく再生する動画。メイン NAS に残す。
コールドデータ：古い動画ライブラリ、アーカイブ資料、長期間動かない大きなファイル。HC620 に移す。
バックアップデータ：定期的に書き込み、たまに読むだけのデータ。これも HC620 に置ける。

HC620 の用途については、サイト内の記事 Western Digital HC620 SMR ディスクの誤解と正しい使い方も参考になります。HC620 は順次書き込み、長期保存、ランダム読み出しには向いていますが、頻繁な削除や繰り返し書き込みの多い用途には向きません。

メイン NAS の空きを確保するだけなら、HDD が高い時期に主 NAS のディスクを一気に交換するのはおすすめしません。まず使用頻度の低いデータを外へ出し、メイン NAS はホットデータを担当し続けるほうが費用対効果は高いです。

古い TerraMaster を使う理由

HC620 の問題は容量ではなく、扱いやすさです。OS、インターフェース、使い方に条件があり、USB HDD ケースへ直接入れる運用にはあまり向いていません。

そこで TerraMaster F2-220、F2-221、または一部の F4 機種を低コストなコールドデータノードとして使います。利点は分かりやすいです。

安い。中古の F2-220 は 200 元以下で見つかることがあります。
小型で場所を取りにくく、消費電力も許容しやすい。
OS を USB メモリに入れられるので、ディスクベイを消費しない。
2 個以上の SATA ベイがあり、HC620 をアーカイブディスクとして載せやすい。

この手の古い機種は性能こそ高くありませんが、コールドデータの移動、CIFS マウント、バックグラウンドコピーには十分です。F2-220 の SATA は古い SATA 3G ですが、実測では HC620 の外周側同士のコピーで約 200MB/s 出ています。コールドデータ移行としては十分で、実際のボトルネックはネットワーク、コピー元ディスクの状態、ファイル数になることが多いです。

オンボードのギガビット LAN に不満がある場合は、USB 2.5G LAN アダプタを追加する方法もあります。コールドデータノードに複雑な改造は不要です。OS がアダプタを認識し、スイッチとメイン NAS も 2.5G に対応していれば、ネットワークの上限を一段引き上げられます。

画面出力を用意する

機種に HDMI がない場合、OS インストール時に VGA が必要です。F2-220 には内部 VGA ヘッダがあります。マザーボード用の内部 12Pin VGA 変換ケーブルを使い、片側を内部ピンヘッダへ、もう片側を標準 VGA コネクタとしてモニタへ接続します。

VGA 変換ケーブルの仕様と注意点は、TerraMaster F2-220 に fnOS を入れる：VGA 出力を参照してください。検索語としては「12Pin VGA 変換ケーブル」「マザーボード 12 ピン VGA 変換」「2.0mm 12Pin to VGA」などが使えます。購入前にピッチ、向き、ピン配列を確認してください。

Ubuntu Server を USB メモリへインストールする

Ubuntu Server は USB メモリへインストールし、HDD ベイはすべてデータディスク用に残すのがおすすめです。

F2-220 は性能が低めなので、本体で直接インストールするとかなり遅くなります。より楽な方法は、USB メモリを別の速い PC に挿して Ubuntu Server をインストールし、完了後に TerraMaster へ戻して起動することです。起動方式が合っていれば、通常そのまま使えます。

インストール後はネットワーク設定を必ず確認します。ネットワークがつながらないと、起動しても SSH で管理できません。

ネットワーク設定

システムに入ったら、まずネットワークインターフェース名を確認します。

`1`	`lshw -c network`

出力例では logical name を確認できます。

  *-network
       description: Ethernet interface
       product: RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:02:00.0
       logical name: enp2s0
       version: 07
       serial: 6c:bf:b5:00:63:ab
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=6.8.0-111-generic duplex=full firmware=rtl8168e-3_0.0.4 03/27/12 ip=192.168.8.205 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:17 ioport:e000(size=256) memory:d0604000-d0604fff memory:d0600000-d0603fff

この例のインターフェース名は enp2s0 です。次に netplan 設定ファイルを編集します。

`1`	`sudo more /etc/netplan/01-install-config.yaml`

ファイルが存在しない場合は新規作成し、次の内容にします。

network:
  version: 2
  ethernets:
    enp2s0:
      dhcp4: true

enp2s0 は実際のインターフェース名に置き換えてください。保存後に実行します。

`1`	`sudo netplan apply`

ネットワークが復旧したら、この TerraMaster に SSH で接続できます。その後はモニタをつなぎっぱなしにする必要はありません。

HC620 を btrfs にフォーマットする

HC620 が新しいディスク、または中のデータが不要だと確認済みなら、先に btrfs にフォーマットします。以下の操作は対象ディスク上のデータを消します。実行前に必ずデバイス名を確認し、メイン NAS の共有ディレクトリやシステム USB メモリを誤ってフォーマットしないようにしてください。

現在のディスクを確認します。

`1`	`lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS`

より安定したディスクパスも確認できます。

`1`	`ls -l /dev/disk/by-id/`

HC620 に対応するデバイス名を確認したら、既存のマウントを解除します。

1
2

sudo umount /dev/sda 2>/dev/null
sudo umount /dev/sda1 2>/dev/null

ディスク全体をそのまま btrfs にする場合は、次を実行します。

`1`	`sudo mkfs.btrfs -f -O zoned -d single -m single -L HC620_01 /dev/sda`

各パラメータの意味は次の通りです。

-f：ファイルシステム作成を強制し、古い署名で止まるのを避ける。
-O zoned：zoned 機能を有効化する。HC620 のようにゾーン単位の順次書き込みが必要なディスクに向く。
-d single -m single：データとメタデータを単一ディスクモードにする。
-L HC620_01：識別しやすいようにラベルを設定する。

システムやカーネルの zoned btrfs 対応が不安定な場合は、以前の実測記録約 600 元の新品 WD HC620 14T は買う価値があるかも参照してください。この種のディスクは、カーネルバージョン、SATA コントローラ、ファイルシステム対応に影響されます。異常がある状態で本番データを入れないほうが安全です。

フォーマット後、まず一時的にマウントして確認します。

1
2
3

sudo mkdir -p /mnt/disk1
sudo mount /dev/sda /mnt/disk1
df -h

正常にマウントできることを確認してから、/etc/fstab に書いて自動マウントします。長期運用では /dev/sda ではなく /dev/disk/by-id/ を使うほうが、再起動後のデバイス名変化を避けられます。

マウントを設定する

このコールドデータノードでは、通常二種類のパスをマウントします。

メイン NAS の共有ディレクトリ。移行対象データを読むために使う。
ローカルの HC620 データディスク。コールドデータとバックアップを保存するために使う。

まずマウントディレクトリを作成します。

`1`	`sudo mkdir -p /mnt/xxxxx /mnt/disk1 /mnt/disk2`

CIFS/SMB 共有をマウントする場合はツールをインストールします。

1
2

sudo apt update
sudo apt install cifs-utils

次に /etc/fstab を編集し、次のような内容を追加します。

1
2
3

//192.168.x.xxx/xxxxx   /mnt/xxxxx cifs auto,username=xxxxx,password=xxxxx,uid=997,gid=997,file_mode=0777,dir_mode=0777,nofail 0 0
/dev/sda  /mnt/disk1  auto  defaults,nofail  0  0
/dev/sdb  /mnt/disk2  auto  defaults,nofail  0  0

1 行目はメイン NAS の共有ディレクトリをマウントします。後ろの 2 行はローカルディスクをマウントします。

実運用では、データディスクには /dev/disk/by-id/ のような安定したパスを使うことをおすすめします。再起動後に /dev/sda と /dev/sdb の順番が変わることを避けるためです。HC620 のフォーマットとマウントの注意点は、以前の記録約 600 元の新品 WD HC620 14T は買う価値があるかも参考になります。

編集後はマウントをテストします。

1
2

sudo mount -a
df -h

メイン NAS の共有ディレクトリとローカルデータディスクが表示されることを確認してから、データ移行を始めます。

バックグラウンドでファイルをコピーする

大量データの移行では、SSH の前景で普通の cp を直接実行するのはおすすめしません。ここでは screen + mc を優先します。screen は SSH が切れてもタスクを残すため、mc は見やすい 2 ペインのファイル管理画面を使うためです。

mc はコールドデータを手作業で整理する用途に向いています。左側にメイン NAS のマウントディレクトリ、右側に HC620 のデータディスクを開き、ファイルを選んで F5 を押すだけでコピーできます。コピー中は現在のファイル進捗と全体進捗が表示されるため、大量ファイルの移動では単なるコマンド出力より分かりやすいです。

上の画像はファイルコピー時の進捗ウィンドウのイメージです。Midnight Commander 公式マニュアルでも、コピー、移動、削除操作は verbose モードでファイル操作ダイアログを表示し、現在ファイルと全体の進捗を表示できると説明されています。

ツールをインストールします。

`1`	`sudo apt install screen mc rsync`

バックグラウンドセッションを開始します。

`1`	`screen -S cold-data`

screen の中で mc を起動します。

mc

基本的な使い方は、左右のペインでコピー元とコピー先を開き、ショートカットで操作する形です。

Tab：左右ペインを切り替える。
Insert：複数のファイルやディレクトリを選択する。
F5：反対側のペインへコピーする。
F6：移動またはリネームする。
F8：削除。慎重に使う。

スクリプト化しやすく、繰り返し実行できる同期が必要な場合は rsync を使います。

`1`	`rsync -avh --progress /mnt/xxxxx/old-data/ /mnt/disk1/old-data/`

コピー中に SSH が切れても、screen セッションは残ります。再接続後に次を実行します。

`1`	`screen -r cold-data`

元のコピー作業へ戻れます。

使用上のおすすめ

この構成はコールドデータとバックアップ向けです。HC620 を高頻度書き込みディスクとして使うのは避けます。おすすめの使い方は次の通りです。

メイン NAS はホットデータと日常サービスを担当する。
HC620 には長期保存の大きなファイル、動画ライブラリ、アーカイブ資料を置く。
データ移行は順次書き込みを中心にし、頻繁な削除や小ファイルの反復書き込みを避ける。
重要データは少なくとも 2 コピー残す。唯一のコピーを 1 台のディスクだけに置かない。
移行後はファイルをサンプル確認し、ディレクトリ数とファイル数が自然か確認する。

今後 HDD 価格が下がれば、メイン NAS アレイの更新を検討しても遅くありません。現時点では、低コストノードで容量圧力を逃がすほうが、リスクと費用の両面で扱いやすいです。

まとめ

NAS の空き容量がなくなっても、すぐに新しいディスクを買って増設する必要はありません。メイン NAS をホットデータ用、HC620 をコールドデータとバックアップ用に分け、安価な TerraMaster F2-220、F2-221、または F4 をマウントとコピー用ノードとして使う構成は、投入コストが低く、実用性の高い一時対応です。

重要なのは性能ではなく役割分担です。メイン NAS は日常利用の快適さを維持し、コールドデータは別に保存する。これにより空き容量を確保しつつ、HDD 高騰期の大きな出費を避けられます。