HC620 SMR HDDでBtrfsが満杯後に読み取り専用になった場合の対処法：安全な空き容量確保とトラブルシューティング

HC620 で Btrfs zoned を使用し、使用率が 100% 近くに達した後で突然書き込めなくなった場合、主な手掛かりは ENOSPC、zone reclaim 用の作業領域不足、またはトランザクションのコミット失敗に伴う強制読み取り専用化です。

ただし、「フル」と「読み取り専用」は障害が発生したときの症状を説明するだけで、ハードディスクが損傷していないことを直接証明することはできません。正しい順序は次のとおりです。

タスクの作成を直ちに中止してください。
障害が発生した場合はカーネルログを保存します。
デバイス、実装ステータス、ゾーン分割されたスペースの配分を確認します。
単純な容量不足、reclaim の停滞、トランザクション中止、下位層の I/O エラーを切り分けます。
証拠が純粋な ENOSPC をサポートしている場合にのみ、読み取り/書き込みモードで再度マウントし、バッチでスペースを解放してみてください。
空き容量を確保した後、低リスクの整理と復旧確認を行います。

読み取り専用になったからといって、すぐに mount -o remount,rw、フィルターなしの balance、または btrfs check --repair を実行しないでください。強制読み取り専用はファイルシステムの保護動作です。まず、その状態を引き起こした最初のエラーを確認します。

この記事では、マウントポイントが /mnt/hc620 であることを前提としています。デバイス名は /dev/sdX でのみ表され、実行前に実際のデバイスまたはパーティションに置き換える必要があります。ドライブ文字をコピーしないでください。

HC620 が満杯になると通常のHDDより空き容量を確保しにくい理由

Western Digital Ultrastar DC HC620 はホスト管理 SMR、つまり書き込み領域がホストによって管理されるシングルディスクです。

Linux は通常、これをゾーン化されたブロックデバイスとして公開します。

1

lsblk -o NAME,MODEL,SIZE,TYPE,FSTYPE,ZONED,MOUNTPOINTS

次のようなものが表示されると予想されます。

1
2


NAME MODEL              SIZE TYPE FSTYPE ZONED        MOUNTPOINTS
sda  HSH721414ALE6M0   12.7T disk btrfs  host-managed /mnt/hc620

実際の型式、容量表示、デバイス名は異なる場合があり、本機の出力が優先されます。

通常の CMR ハードドライブは、割り当てられたセクタを上書きする可能性があります。ホスト管理 SMR のシーケンシャル書き込みゾーンは、現在の書き込みポインタから書き込みを続行する必要があります。書き込まれたゾーンを再利用するには、通常、まだ有効なデータを最初に移動してから、ゾーン全体をリセットする必要があります。

Btrfs は、Linux 5.12 以降でゾーンモードをサポートします。 COWを使用しています。ファイルが上書きされたり、メタデータが更新または削除されたりすると、古いデータブロックはファイルシステムによって参照されなくなりますが、すぐに再書き込み可能な空のゾーンになるわけではありません。

これらのスペースは、btrfs filesystem usage では次のように表示されます。

1

Device zone unusable

これは「永久に損傷したハードディスク容量」を意味するのではなく、過去に書き込まれ、現在は参照されていないものの、再利用する前にブロックグループの再利用とゾーンのリセットを行う必要がある領域のことです。

reclaim 処理では、ゾーン内でまだ有効なデータを新しい場所へ移動する必要があります。移動先となる新しいゾーンが不足すると、一時的な ENOSPC が発生する可能性があります。

したがって、HC620 では次のようになります。

1

文件层面删除了 1 TiB

必ずしも次と直ちに等しいわけではありません:

1

底层马上多出 1 TiB 可写空间

これは、ゾーン化された Btrfs が実際に限界まで書き込まれた後、通常のディスクよりもサイトで処理するのが難しい理由でもあります。

最初に停止するタスク

マウントポイントが読み取り専用であることが判明した後は、元のコピータスクを繰り返し再試行しないでください。

まず、I/O またはログノイズを発生し続ける可能性のある次のようなサービスを停止します。

rsync、rclone、またはダウンロードタスク。
コンテナと仮想マシン。
メディアライブラリのスキャン。
スケジュールされたスナップショットとバックアップ。
タスクのスクラブ、バランス調整、または一括削除。

まずバランスまたはスクラブがあるかどうかを確認します。

1
2


sudo btrfs balance status /mnt/hc620
sudo btrfs scrub status /mnt/hc620

この記事の手順を実行するためにタスクを自動的にキャンセルしないでください。まずステータスを記録します。バランスまたはスクラブが実行中で、システムがまだ応答している場合は、ログを結合して、それが障害サイトの一部であるかどうかを判断する必要があります。

どのプロセスがまだマウントポイントを占有しているかを確認します。

1

sudo fuser -vm /mnt/hc620

このコマンドは監視のみを目的としており、プロセスは自動的に終了しません。

アンマウントや再起動の前に障害ログを保存する

dmesg で最も価値のあるものは、多くの場合、最後の行 forced readonly ではなく、その前の最も古いエラーです。

まず、完全なカーネルログをシステムディスクなどの別の通常のディスクに保存します。

1

sudo journalctl -k -b --no-pager > "$HOME/hc620-kernel-current-boot.log"

次に、関連する行を抽出します。

1
2
3


sudo dmesg -T | \
grep -iE 'btrfs|enospc|no space|transaction|abort|forced readonly|zone|I/O error' | \
tail -200

マシンが再起動されている場合は、最後の起動を確認します。

1
2


sudo journalctl -k -b -1 --no-pager | \
grep -iE 'btrfs|enospc|no space|transaction|abort|forced readonly|zone|I/O error'

システムに永続的なジャーナルがない場合、最後の起動時のログが存在しない可能性があります。したがって、障害サイトは最初にログのエクスポートを試みてから、再起動する必要があります。

基本環境も保存します。

1
2
3
4


uname -a
btrfs version
lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE,FSTYPE,ZONED,MOUNTPOINTS
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/hc620

このうち、findmnt の OPTIONS に ro が含まれている場合、現在のマウントが読み取り専用であることは確認できるだけで、なぜ読み取り専用になったのかは説明できません。

デバイスを特定し、推測で `/dev/sdX` を指定しない

まずマウントポイントからソースデバイスを確認します。

1

findmnt -no SOURCE /mnt/hc620

ファイルシステム内のデバイスを再度確認します。

1

sudo btrfs filesystem show /mnt/hc620

安定したデバイスリンクを確認します。

1

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

ファイルシステムがパーティション上に構築されている場合、後続のマウントではディスク全体ではなくパーティションを使用する必要があります。たとえば、実際のソースデバイスが /dev/sda1 の場合、/dev/sda と記述することはできません。

実際の結果を変数として記録する場合は、手動による検証も必要です。

1
2
3
4
5


DEV=/dev/disk/by-id/你的实际设备或分区链接
MNT=/mnt/hc620

lsblk -f "$DEV"
findmnt "$MNT"

例にある中国語のプレースホルダーをそのまま実行しないでください。

Btrfs 空間分布の読み取り

ファイルシステムがまだマウントされている間に実行します。

1
2
3


sudo btrfs filesystem usage -T /mnt/hc620
sudo btrfs filesystem df /mnt/hc620
sudo btrfs device usage /mnt/hc620

重要なメモ:

1
2
3
4
5
6
7


Device size
Device allocated
Device unallocated
Device zone unusable
Data,single
Metadata,single 或 Metadata,DUP
Global reserve

典型的な高リスクのポートフォリオは次のようになります。

1
2
3
4
5


Device allocated:       接近 Device size
Device unallocated:     0.00 B 或非常少
Device zone unusable:   数十至数百 GiB
Data 使用率:            接近 100%
Metadata 使用率:        很高

df -h だけを見ないでください。 Btrfs のデータ、メタデータ、システムブロックグループ、およびデバイスの未割り当てスペースは異なるレベルにあります。 COW には、トランザクションを完了するための新しいスペースも必要です。

Device zone unusable を単独で障害の結論として使用することはできません。

ゼロ以外の値は、ゾーン COW が動作した後の通常の現象です。
値が非常に大きく、Device unallocated が 0 に近い場合、再利用可能な領域とすぐに割り当て可能な領域が大きくずれていることを意味します。
値はバックグラウンド収集中に変更される可能性があります。
たとえ 0 であっても、メタデータの枯渇や根本的な I/O エラーが除外されるわけではありません。

永続化されたデバイスエラーカウンターを確認する

埋め込む：

1

sudo btrfs device stats /mnt/hc620

通常の出力例:

1
2
3
4
5


[/dev/sda].write_io_errs    0
[/dev/sda].read_io_errs     0
[/dev/sda].flush_io_errs    0
[/dev/sda].corruption_errs  0
[/dev/sda].generation_errs  0

各項目の意味:

write_io_errs: 下位ブロックデバイスは書き込みリクエストを完了できませんでした。
read_io_errs: 下位ブロックデバイスは読み取りリクエストを完了できませんでした。
flush_io_errs: トランザクション配置の順序に関連して、FLUSH による書き込みが失敗しました。
corruption_errs: チェックサムの不一致または破損したメタデータヘッダーが見つかりました。
generation_errs: ブロックの生成は親ノードの期待と一致しません。

すべて 0 は良好な兆候ですが、ドライブが正常であることを証明するものではありません。カーネルログ、SMART、HBA、リンクエラー判定も組み合わせます。

まだ使用しないでください:

1

sudo btrfs device stats -z /mnt/hc620

-z は印刷後にカウントをクリアします。保存する前に障害の証拠が消去されると、重要なベースラインが失われます。

エラーが増加し続けるかどうかを実際に観察したい場合は、まず現在の出力を保存してから時間を記録します。

1
2


date -Is
sudo btrfs device stats /mnt/hc620

単一のスナップショットだけを見るのではなく、管理されたテストを完了した後に再度比較してください。

ログから障害を4種類に切り分ける

種類1：単純な容量不足または一時的な ENOSPC

このカテゴリーを裏付けるさらなる証拠には次のようなものがあります。

1
2
3
4


No space left on device
ENOSPC
transaction aborted
forced readonly

両方を満たす:

btrfs device stats にはゼロ以外のエラーはありません。
ログには I/O error はありません。
チェックサム、ツリーチェッカー、破損したリーフまたは親のtransidエラーはありません。
ファイルシステムは確かに満杯に近づいています。
Device unallocated はまれであるか、ゾーン化されたリサイクルが大幅に制限されています。

この状況は、後の「制御された読み取り/書き込みマウントと領域の解放」プロセスに入るのに適しています。

種類2：zone reclaim または block group reclaim が停滞している

次のようなログが表示される場合があります。

1
2
3
4
5


btrfs-cleaner
btrfs_delete_unused_bgs
btrfs_zone_finish
do_zone_finish
blocked for more than ... seconds

この時点での問題は、必ずしも容量値がゼロになるだけではなく、パスのリサイクル、長いロック待機、または特定のカーネルでのゾーン化されたアクティブゾーン制限も関係する可能性があります。

この時点でフィルターなしの balance を追加実行しないでください。まずコールスタック、カーネルバージョン、完全なログを保存し、サイト内の実際の障害事例を参照してください。

[HC620 での 2 つの Btrfs ゾーン障害のレビュー: ロックアップ、読み取り専用、およびカーネルのトラブルシューティング] (/ja/2026/07/24/hc620-btrfs-zoned-deadlock-readonly-troubleshooting/)

種類3：トランザクションは中止されたが原因が未特定

次の行は結果のみを説明しています。

1
2
3


transaction aborted
BTRFS error
forced readonly

本当の理由は通常、事前にあります。最初のエラー、戻りコード、呼び出しスタックを見つけるには、数十から数百行を検索する必要があります。

すべての transaction aborted をフルとして分類することはできません。低レベルの書き込み失敗、メタデータ検証の失敗、カーネルのバグによってもトランザクションが中止される可能性があります。

種類4：I/O、チェックサム、または構造エラー

次のいずれかの手がかりが表示された場合は、「いくつかのファイルを削除すれば解決する」というプロセスを中止する必要があります。

1
2
3
4
5
6
7
8
9


I/O error
write_io_errs
read_io_errs
flush_io_errs
checksum error
corrupt leaf
parent transid verify failed
tree-checker
zone write pointer

現時点では、データコピーの保護と、ディスク、SAS/SATA HBA、ケーブル、電源、およびカーネルゾーンエラーのチェックが優先されます。ゼロ以外のデバイス数を単純に「単なるディスクがいっぱいである」と解釈しないでください。

先に読み取り専用でマウントしてデータを救出する

現在のマウントがまだ読み取れる場合は、他にコピーがない最も重要なデータを最初にコピーします。

アンマウントしてから再マウントする必要がある場合は、まず対象ディレクトリを使用しているシェルを終了してから、次のコマンドを実行します。

1
2


cd /
sudo umount /mnt/hc620

アンマウントされたことを確認します。

1

findmnt /mnt/hc620

出力がない場合は、マウントポイントが現在のマウントテーブルにないことを意味します。

最初は読み取り専用モードでマウントします。

1
2


sudo mount -o ro "$DEV" /mnt/hc620
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/hc620

次に、重要なファイルを別の正常なディスクにコピーします。読み取り専用レスキュー中にターゲットディレクトリを HC620 自体に戻さないでください。

通常の読み取り専用マウントが失敗した場合は、rescue= パラメータをランダムに重畳しないでください。エラーが異なれば、必要なレスキューオプションも異なります。エラーパラメータによりログが隠蔽されたり、読み取り結果が変化したりする可能性があります。決定は、特定のエラーレポートに基づいて行う必要があります。

読み書き可能な再マウントを試せる条件

以下の条件が同時に満たされる場合、制御された試行が考慮される場合があります。

障害ログが保存されました。
重要なデータに別のコピーがあるか、読み取り専用のレスキューが先に完了しています。
ログの最初の理由は、明らかに ENOSPC を示しています。
I/O、チェックサム、ツリーチェッカー、またはゾーン書き込みポインターのエラーはありません。
btrfs device stats には例外カウントはありません。
スタックした古いカーネルタスクはありません。
ファイルシステムは完全にアンマウントできます。

まず読み取り専用マウントをアンマウントします。

1

sudo umount /mnt/hc620

現在のエラーステータスを抑制するために remount,rw を使用せずに、通常のマウントを再度実行します。

1

sudo mount "$DEV" /mnt/hc620

今すぐ確認してください:

1
2


findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/hc620
sudo dmesg -T | tail -100

マウントオプションにまだ ro が含まれている場合、またはトランザクションの中止がログに再び表示される場合は、試行を中止し、アンマウントとマウントを繰り返さないでください。

rw が正常に表示された場合でも、レプリケーションサービスをすぐに復元しないでください。読み取り/書き込みウィンドウの最初のタスクは、既知の削除可能なデータをバッチで解放することです。

読み書き可能に戻った後、安全に空き容量を確保する方法

他にコピーがあることが確認されており、再構築が可能で、サイズが大きいディレクトリを優先してください。

まず、第 1 レベルのディレクトリのサイズを確認します。

1

sudo du -xhd1 /mnt/hc620 | sort -h

直接コピーしないでください:

1

rm -rf /mnt/hc620/某个大目录

変数展開エラーがないことを確認するために、最初に実際のターゲットを出力する必要があります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


DELETE_TARGET=/mnt/hc620/已确认可删除的实际目录
DELETE_TARGET=$(realpath -e -- "$DELETE_TARGET") || exit 1

case "$DELETE_TARGET" in
  /mnt/hc620/*) ;;
  *) printf '拒绝删除挂载点之外的路径：%s\n' "$DELETE_TARGET" >&2; exit 1 ;;
esac

printf '%s\n' "$DELETE_TARGET"
sudo du -sh -- "$DELETE_TARGET"
sudo find "$DELETE_TARGET" -xdev -maxdepth 1 -mindepth 1 -printf '%f\n' | head

削除する前に、ターゲットが正しいことを確認してください。

1
2


sudo rm -rf -- "$DELETE_TARGET"
sync

マルチテラバイトのデータの場合は、個別のサブディレクトリまたはバッチで削除し、同時に大規模な書き込みを実行しないことをお勧めします。

各バッチの後に確認してください:

1
2
3
4


sudo btrfs filesystem sync /mnt/hc620
sudo btrfs filesystem usage -T /mnt/hc620
sudo btrfs device stats /mnt/hc620
sudo dmesg -T | tail -100

btrfs filesystem sync しばらく時間がかかる場合があります。コマンドが戻る前に、領域の回復が完了したため、「ディレクトリが消えた」と誤解しないでください。

数 GiB を削除してすぐに埋めるのではなく、まず数百 GiB を解放することを目指します。具体的な安全マージンは、ワークロード、ゾーンサイズ、メタデータ、リサイクル効率によって異なり、すべての HC620 に対して絶対的な比率を与えることはできません。

長期間使用する場合、ゾーン化された Btrfs を 99% ～ 100% に維持することはお勧めできません。両方を予約するには:

毎日新しい書き込みスペース。
COW トランザクションスペース。
メタデータの成長スペース。
ゾーン再利用は、有効なデータがまだあるワークスペースを移動します。
緊急削除およびメンテナンス期間。

スペースを削除してもすぐに戻らない理由

ファイルを削除すると、主にメタデータの参照解除と更新が行われます。ゾーン化されたデバイスの場合、関連するゾーンに有効なエクステントが存在する可能性があるため、Btrfs はゾーンをリセットする前にそれらを移動する必要があります。

したがって、次のように表示されるかもしれません。

ファイルは削除されました。
Used は拒否されました。
Device zone unusableは一時的に上昇します。
Device unallocated は、削除量に応じて同期的に増加しません。
バックグラウンドクリーナーは I/O を生成し続けます。

これは、必ずしも削除が失敗したことを意味するわけではありません。完全に管理されたリサイクルサイクルを観察し、ログと btrfs filesystem usage -T の傾向に基づいて判断します。

値が長期間変更されず、クリーナーブロッキング、トランザクションエラー、または D ステートタスクが同時に発生した場合は、大量のデータを削除し続けるのではなく、回復パスの障害に応じて処理する必要があります。

balance は空き容量を確保してから段階的に実行する

バランスによってブロックグループが移動します。ほとんどのバランス操作では、まず新しいブロックグループをワークスペースとして作成する必要があるため、ディスクがいっぱいのときにフィルターを使用せずにバランスを直接実行すると、再び ENOSPC がトリガーされる可能性があります。

すぐに実行しないでください。

1

sudo btrfs balance start /mnt/hc620

まず、balance が現在実行されていないことを確認します。

1

sudo btrfs balance status /mnt/hc620

ログが安定しており、スペースが解放され、デバイスエラー数が増加していないという前提で、最初に完全に未使用のブロックグループを処理できます。

1

sudo btrfs balance start -dusage=0 -musage=0 /mnt/hc620

usage=0 は追加のワークスペースを必要とせず、Btrfs の公式ドキュメントで提供されている ENOSPC の低リスクの開始点です。

完了後の確認:

1
2
3
4


sudo btrfs balance status /mnt/hc620
sudo btrfs filesystem usage -T /mnt/hc620
sudo btrfs device stats /mnt/hc620
sudo dmesg -T | tail -100

低いしきい値は、スペースとログの両方が安定している場合にのみ考慮されます。

1

sudo btrfs balance start -dusage=5 /mnt/hc620

再度観察すると、次のように改善できる可能性があります。

1

sudo btrfs balance start -dusage=20 /mnt/hc620

これらの数値は、段階的に実行する必要がある固定の処方箋ではありません。しきい値が高くなるほど、より多くのデータが移動される可能性があり、より多くの作業スペースと I/O が必要になります。

btrfs-cleaner、ブロックグループの削除、またはゾーン終了パスが以前にスタックしている場合は、バランスを自動修復とはみなしません。同様のコードパスに再び入る可能性があるため、最初にカーネルの問題を調査する必要があります。

障害が発生したディスクで避けるべき操作

読み書き可能への強制 remount を行わない

避ける：

1

sudo mount -o remount,rw /mnt/hc620

カーネルがエラーのためにファイルシステムを読み取り専用に強制したばかりの場合、直接再マウントでは「ログの保存、アンマウント、および再評価」の境界がスキップされ、通常は読み取り専用ファイルシステムの根本原因を取り除くことはできません。

フィルターなしの balance を安易に実行しない

避ける：

1

sudo btrfs balance start /mnt/hc620

ディスクのバランスがフルになるとデータを移動する必要があり、元の障害よりも多くの一時スペースが必要になる場合があります。

`btrfs check --repair` を実行しないでください

避ける：

1

sudo btrfs check --repair /dev/sdX

Btrfs の公式ドキュメントでは、開発者または経験豊富な担当者から特定のエラーについてアドバイスがない限り、--repair を使用しないでくださいと明確に警告しています。

オフラインの構造チェックが本当に必要な場合は、先にアンマウントし、デフォルトの読み取り専用モードを使用します。

1

sudo btrfs check --readonly "$DEV"

ただし、14 TB または 15 TB のファイルシステムでは、このチェックに時間がかかり、大量のメモリを消費し、連続読み取りが発生する可能性があります。純粋な ENOSPC の証拠しかない場合、これは通常、最初のステップとして必要ありません。

最初にデバイスエラー統計をクリアしないでください

証拠を保存する前に実行しないでください。

1

sudo btrfs device stats -z /mnt/hc620

ゼロ調整はドライブ、ケーブル、または HBA を修復するものではなく、単に比較ベースラインを消去するだけです。

大量削除と大量書き込みを同時に続けない

ホスト管理 SMR での数テラバイトの削除、ゾーンの再利用、および数テラバイトの新規書き込みが重なると、障害面が大幅に拡大する可能性があります。

より信頼性の高いプロセスは次のとおりです。

1
2
3
4
5
6


停止新写入
→ 分批删除
→ 等待事务提交与回收
→ 检查空间和日志
→ 保留明显余量
→ 再分批恢复写入

空き容量回復後の検証

rw の復元は始まりにすぎず、最終的な成功基準として使用することはできません。

マウントステータスを確認する

1

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/hc620

確認する：

ソースデバイスは正しいです。
ファイルシステムは btrfs です。
マウントオプションには rw が含まれます。
間違ったサブボリュームやパーティションがマウントされていません。

空間分布を検証する

1
2


sudo btrfs filesystem usage -T /mnt/hc620
sudo btrfs device usage /mnt/hc620

単に Device zone unusable ゼロを選択しないでください。さらに:

利用可能なスペースはすでに十分にあります。
Device unallocated または割り当て可能なスペースが復元されました。
メタデータはもはや限界まで追い詰められることはありません。
reclaim 処理中に新たなエラーが発生していない。

エラーカウンターが増加していないことを確認する

1
2


date -Is
sudo btrfs device stats /mnt/hc620

失敗後に保存されたベースラインと比較します。 write_io_errs、flush_io_errs、corruption_errs、または generation_errs が大きくなった場合は、大規模な書き込みの再開を停止します。

カーネルが再び読み取り専用を強制していないことを確認します

1
2


sudo journalctl -k --since '-30 min' --no-pager | \
grep -iE 'btrfs|enospc|no space|transaction|abort|forced readonly|zone|I/O error'

新しく生成されたログに注意し、数時間前の古いエラーが再発したと誤判断しないようにしてください。

小規模な書き込みテストを実行する

まず、クリアなテストディレクトリに書き込みます。

1
2
3
4
5


TEST_DIR=/mnt/hc620/.recovery-test
sudo mkdir -p "$TEST_DIR"
sudo dd if=/dev/zero of="$TEST_DIR/test.bin" bs=1M count=1024 status=progress
sync
sudo sha256sum "$TEST_DIR/test.bin"

テストファイルを削除して、再度送信します。

1
2
3


sudo rm -f "$TEST_DIR/test.bin"
sudo rmdir "$TEST_DIR"
sudo btrfs filesystem sync /mnt/hc620

次に、ログ、スペース、デバイスの統計を再度確認します。

1GiB テストに合格した場合、小規模な書き込みが成功したことのみを証明できますが、数 TB の連続書き込みが必ずしも安定していることは証明できません。正式なタスクは小さなバッチで再開し、監視する必要があります。

冗長性またはバックアップを確保してから scrub を実行する

スクラブは、割り当てられたすべてのデータを読み取り、チェックサムを検証しますが、これには長い時間がかかる場合があります。新しく復元されたフルディスクに対してバランス、コピー、削除をすぐに同時に実行しないでください。

ファイルシステムが安定しており、重要なデータのコピーがあることを確認したら、独立したメンテナンス期間をスケジュールします。

1

sudo btrfs scrub start -Bd /mnt/hc620

完了したら確認してください:

1
2


sudo btrfs scrub status /mnt/hc620
sudo btrfs device stats /mnt/hc620

単一ディスクの single データには、Btrfs が自動的に修復するための別のミラーがありません。スクラブが検証の問題を発見できるからといって、必ずしもそれを修正できるとは限りません。

長期的に再び満杯になることを避ける方法

書き込みタスクの容量停止ラインを設定する

バックアップスクリプトにコマンドの終了コードだけを確認させないでください。書く前と後の両方を記録します。

1
2


df -h /mnt/hc620
sudo btrfs filesystem usage -T /mnt/hc620

利用可能なスペースがメンテナンスのしきい値を下回ると、新しいデータの受信を停止し、警告を発します。

しきい値は、「次のファイルにどれだけのスペースが収まるか」に基づいて計算するだけでなく、COW、メタデータ、およびゾーン再利用のためのスペースも含める必要があります。

大規模な削除と大規模な書き込みを時間差で実行する

推薦する：

1
2
3
4
5


复制一批
→ 校验一批
→ 等待事务稳定
→ 删除一批旧数据
→ 再检查 zone 与日志

同じメンテナンス期間中に、rsync、スナップショットの削除、スクラブ、バランスの I/O 競合をスケジュールしないでください。

アーカイブデータの外部チェックサム一覧を保持する

重要なディレクトリのチェックリストを生成し、そのリストを別のディスクにコピーできます。

1
2


cd /mnt/hc620/archive
find . -type f -print0 | sort -z | xargs -0 sha256sum > /另一块盘/archive.sha256

ファイル名に改行が含まれている場合、上記のテキストマニフェスト形式は依然として扱いにくい場合があります。データソースが特殊なファイル名を生成する場合は、NUL 区切りをサポートする専用のマニフェストプロセスを使用する必要があります。

単一ディスクファイルシステムをバックアップとして扱わないでください。

Btrfs チェックサムはサイレント破損を検出できますが、単一ディスクのデータプロファイルには通常、回復するためのデータの 2 番目のコピーがありません。

HC620 のデータには少なくとも以下も含まれている必要があります。

別のローカルディスクコピー。
別のマシンまたはオフサイトのコピー。
定期的に検証可能なオブジェクトストレージまたはオフラインレプリカ。

よくある質問

`Device zone unusable` は非常に大きいです。ディスクが壊れているということでしょうか？

不確かな。これは、過去に書き込まれ、COW により参照されなくなったが、まだ回収されておらず、ゾーンがリセットされていないスペースを表します。

Device unallocated、データとメタデータの使用状況、カーネルログ、リサイクル傾向、デバイスエラー数も確認する必要があります。

ファイルを削除した後、すぐに同じ容量を復元できますか?

保証されていません。削除すると、まずファイルシステム参照が変更されます。基礎となるゾーンでも、有効なデータを移動してリセットする必要がある場合があります。

通常の再マウントに成功したら、再び満杯まで書き込んでもよいですか？

いけません。まず十分な余裕を確保し、ログとエラーカウンターが安定していることを確認します。その後、小規模なテストを実施し、最後に処理を小分けにして再開します。

`write_io_errs` は 0 ですが、ハードディスクの問題は除外されますか?

それを完全に排除することはできません。これは、Btrfs によって記録されたこのタイプの永続性カウントに書き込み失敗がないことを示しているだけです。カーネルブロック層のログ、SMART、HBA、ワイヤ、電源も確認してください。

`mount -o recovery` は使用できますか?

古いチュートリアルの recovery をユニバーサル修復スイッチとは考えないでください。現在の Btrfs レスキューマウントオプションには明確に該当するエラーがあり、通常は読み取り専用マウントが必要であり、実際のログに基づいて選択する必要があります。

まだスペースがあることが示されているのに、`df` が ENOSPC を報告するのはなぜですか?

Btrfs の COW、データおよびメタデータブロックグループ、トランザクション予約、ゾーン再利用はすべてスペースを必要とします。 df によって示されるファイルレベルの利用可能な推定値は、これらの内部制約を完全には表現していません。

メタデータを DUP からシングルに変更する必要がありますか?

スペースを圧迫するためだけにプロファイルを一時的に変更しないでください。プロファイル変換自体にはブロックグループの移動が必要であり、これには作業スペースと大量の I/O が必要です。ゾーンモードでサポートされるプロファイルは、カーネルとツールのバージョンにも影響されます。

`usage=0` の balance が比較的安全な理由

完全に未使用のブロックグループのみをスキャンして再利用するため、公式ドキュメントには、このフィルターには追加のワークスペースは必要ないと記載されています。

「比較的安全」でも、すべての障害に適しているわけではありません。reclaim 経路の停止や構造エラーがログに示されている場合は、作業を止めて先に分析します。

直接電源を切って再起動することは可能でしょうか？

システムがまだ応答している場合は、ログを保存し、タスクを停止し、必要なトランザクションを待って、通常どおりアンマウントします。強制的な電源断は、未コミットの書き込みと障害分析の不確実性を増やします。

カーネルタスクが長時間にわたって中断不可能な D 状態にあり、マシンが正常にシャットダウンできない場合は、再起動のリスクを評価する前に、別のマシンまたはリモートコンソールを通じてできるだけ多くのログを保存する必要があります。

実行順に並べた障害対応チェックリスト

順番に実行します。バランス調整や修復にジャンプしないでください。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


1. 停止复制、下载、容器、快照和维护任务
2. 保存当前及上一次启动的内核日志
3. 用 findmnt 和 lsblk 确认设备、分区、zoned 与 ro/rw
4. 保存 btrfs filesystem usage -T
5. 保存 btrfs device stats，不清零
6. 找到 forced readonly 前的第一条错误
7. 区分 ENOSPC、回收阻塞、事务异常和 I/O/结构错误
8. 有重要数据时先只读挂载并复制到另一块盘
9. 仅在纯 ENOSPC 证据充分时尝试一次普通读写挂载
10. 读写成功后分批删除已确认可重建的数据
11. 每批后 sync，并检查空间、日志和错误计数
12. 空间充裕且日志稳定后，才考虑 usage=0 balance
13. 做小规模写入、删除与校验测试
14. 独立维护窗口再安排 scrub
15. 给未来写入设置容量停止线和外部告警

次の診断に必要な出力

それでも自分がどのカテゴリに属しているかを確認できない場合は、次の出力を収集するときにシリアル番号などの機密情報を非表示にしますが、エラーコンテキストは削除しないでください。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


uname -a
btrfs version

lsblk -o NAME,MODEL,SIZE,TYPE,ZONED,FSTYPE,MOUNTPOINTS
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/hc620

sudo btrfs filesystem usage -T /mnt/hc620
sudo btrfs device stats /mnt/hc620

sudo journalctl -k -b --no-pager | \
grep -iE 'btrfs|zone|enospc|no space|I/O error|transaction|abort|forced readonly' | \
tail -200

これらの出力に基づいて、次のステップは通常次のように収束します。

埋めるだけでスペースをコントロールできます。
ゾーン再利用にはワークスペースや再利用パスのブロックがありません。
Btrfs トランザクションは中止されるため、最初のエラーを追跡する必要があります。
HC620、HBA、ケーブル、または電源上の実際の I/O 障害。
ファイルシステムに検証エラーまたは構造エラーがあるため、まずデータを救出してから、経験豊富な担当者が処理する必要があります。

参考文献

満杯になった HC620 が読み取り専用になったとき、最優先すべきことは、急いで rw 表示へ戻すことではありません。まず、カーネルが保護のため読み取り専用へ切り替えた理由を特定します。単純な ENOSPC だと裏付けられた場合に限り、ログとデータのコピーを確保してから、管理された手順で空き容量を増やします。I/O、チェックサム、構造、または zone write pointer のエラーが出た場合は書き込みを止め、データ救出とハードウェア経路の調査を優先してください。

HC620 が満杯になると通常のHDDより空き容量を確保しにくい理由

最初に停止するタスク

アンマウントや再起動の前に障害ログを保存する

デバイスを特定し、推測で /dev/sdX を指定しない

Btrfs 空間分布の読み取り

永続化されたデバイスエラーカウンターを確認する

ログから障害を4種類に切り分ける

種類1：単純な容量不足または一時的な ENOSPC

種類2：zone reclaim または block group reclaim が停滞している

種類3：トランザクションは中止されたが原因が未特定

種類4：I/O、チェックサム、または構造エラー

先に読み取り専用でマウントしてデータを救出する

読み書き可能な再マウントを試せる条件

読み書き可能に戻った後、安全に空き容量を確保する方法

スペースを削除してもすぐに戻らない理由

balance は空き容量を確保してから段階的に実行する

障害が発生したディスクで避けるべき操作

読み書き可能への強制 remount を行わない

フィルターなしの balance を安易に実行しない

btrfs check --repair を実行しないでください

最初にデバイスエラー統計をクリアしないでください

大量削除と大量書き込みを同時に続けない

空き容量回復後の検証

マウントステータスを確認する

空間分布を検証する

エラーカウンターが増加していないことを確認する

カーネルが再び読み取り専用を強制していないことを確認します

小規模な書き込みテストを実行する

冗長性またはバックアップを確保してから scrub を実行する

長期的に再び満杯になることを避ける方法

書き込みタスクの容量停止ラインを設定する

大規模な削除と大規模な書き込みを時間差で実行する

アーカイブデータの外部チェックサム一覧を保持する

単一ディスク ファイル システムをバックアップとして扱わないでください。

よくある質問

Device zone unusable は非常に大きいです。ディスクが壊れているということでしょうか？

ファイルを削除した後、すぐに同じ容量を復元できますか?

通常の再マウントに成功したら、再び満杯まで書き込んでもよいですか？

write_io_errs は 0 ですが、ハードディスクの問題は除外されますか?

mount -o recovery は使用できますか?

まだスペースがあることが示されているのに、df が ENOSPC を報告するのはなぜですか?

メタデータを DUP からシングルに変更する必要がありますか?

usage=0 の balance が比較的安全な理由

直接電源を切って再起動することは可能でしょうか？

実行順に並べた障害対応チェックリスト

次の診断に必要な出力

参考文献

デバイスを特定し、推測で `/dev/sdX` を指定しない

`btrfs check --repair` を実行しないでください

単一ディスクファイルシステムをバックアップとして扱わないでください。

`Device zone unusable` は非常に大きいです。ディスクが壊れているということでしょうか？

`write_io_errs` は 0 ですが、ハードディスクの問題は除外されますか?

`mount -o recovery` は使用できますか?

まだスペースがあることが示されているのに、`df` が ENOSPC を報告するのはなぜですか?

`usage=0` の balance が比較的安全な理由