大容量ドライブを追加した後にBtrfsのバランス処理が停止したように見えるのは、再配置にまだ空きチャンクの作業領域が必要で、ファイルシステム全体を移動している可能性があるためです。
大容量デバイスにデータを置き換えたりコピーしたりしても、すべてのBtrfsブロックグループが自動的にコンパクト化され、均等に分散され、再配置可能になるわけではありません。バランス処理はブロックグループ単位で実行され、一時的な作業領域を作成してメタデータを更新します。また、最も遅いデバイス、スナップショット、チェックサム、その他の排他的処理によって制限されることがあります。まず、本当に再配置が停止しているのか、処理が進行中の低速なフルバランスなのかを見分ける必要があります。
バランス処理が実行中、一時停止中、または待機中か確認する
バランスの状態、処理済みチャンク数、カーネルログ、ディスクスループット、デバイスごとのレイテンシを確認します。コマンドがフォアグラウンド、バックグラウンド、一時停止、キャンセルのいずれで実行されているか、また再起動後に自動再開されたかを記録してください。
バランス処理では、使用率の高いブロックグループを1つ再配置するだけで、表示されるカウンターが変化するまで長時間かかることがあります。ArchWikiのBtrfsガイドでは、バランス状態とファイルシステム使用状況を使って、処理が継続しているのか、コマンドがすでに停止しているのかを判断する方法が示されています。
I/Oがなく、状態にも変化がなく、カーネルログにエラーが記録されている場合は、低速なのではなく停止していると判断してください。異なるフィルターでバランスを再開する前に、最初に発生したエラーメッセージを保存します。
大容量デバイスとファイルシステムのサイズが変更されているか確認する
物理デバイスのサイズ、パーティションサイズ、Btrfsデバイスサイズ、ファイルシステムの割り当て容量を比較します。大容量の交換ディスクでも、古いパーティション境界や古いBtrfsデバイスサイズのままになっている可能性があります。
ハードウェア容量、パーティションテーブル、ブロックデバイス、Btrfsデバイス一覧、ファイルシステムの割り当て容量の順に、各層を確認してください。SUSEの説明によると、ファイルシステムを拡張する前にデバイスを拡張する必要があります。Btrfsがまだ認識していない容量を、バランス処理で使用することはできません。
ZimaSpaceのドライブ交換後に容量が増えない場合の記事では、再配置を原因と判断する前に行う、関連する階層別の確認について説明しています。
空きバイト数と空きチャンク作業領域を区別する
デバイス全体のサイズと、Btrfsのブロックグループにすでに割り当てられている容量を比較します。ユーザーから見て空き容量があっても、再配置に必要な一時ブロックグループを作成できるほど大きな完全未割り当て領域がない場合があります。
Btrfsのバランスに関するドキュメントでは、再配置には完全に未使用のブロックグループ作業領域が必要だと説明されています。これは通常のファイルレベルの空き容量とは異なり、バランス処理中にENOSPCが発生する原因になります。
作業領域が不足している場合は、まず使用率フィルターを絞り、完全に未使用のブロックグループを解放します。チャンク割り当てへの影響を測定する前に、スナップショットを無差別に削除しないでください。
フィルターなしでフルバランスを開始していないか確認する
最初に実行したコマンドを確認します。データまたはメタデータのフィルターなしでバランス処理を実行すると、実際の目的が使用率の低いチャンクのコンパクト化や、特定デバイスからの割り当て移動だけであっても、ファイルシステム全体の再配置が試みられます。
選択されたすべてのブロックグループが書き換えられるため、フルバランスには数時間から数日かかることがあります。Linuxのbtrfs-balanceマニュアルでは、フィルターなしで実行するとファイルシステム全体でデータとメタデータが移動され、すべてのブロックポインターが更新されると警告しています。
状態出力と以前のシェル履歴を使って、現在有効なフィルターを特定します。バランス処理を何度もキャンセルして再開しないでください。中断されたバランス処理によって、部分的に埋まったブロックグループが残り、作業領域を消費し続けることがあります。
低速なデバイス、エラー、競合する排他的処理を確認する
SMARTデータ、転送エラー、リンクリセット、USBまたはSATAのタイムアウト、デバイスごとのレイテンシを確認します。バランス処理の速度は、古い場所からの読み取り、新しい場所への書き込み、チェックサム検証、メタデータ更新によって制限されます。
スクラブ、デバイスの追加または削除、ファイルシステムのサイズ変更、スナップショットの削除、送信または受信、その他のストレージ処理も確認してください。Red HatのBtrfs管理ガイドでは、デバイス変更とバランス処理を再配置操作として説明しています。そのため、ディスクに障害がなくても、処理が重なると大きな競合が発生する可能性があります。
いずれかのデバイスでリセットが繰り返されたり、レイテンシが極端に高かったりする場合は、バランス処理を一時停止し、さらに再配置を強制する前に、その経路を診断してください。不安定なデバイスで処理を続けると、パフォーマンスの問題が復旧作業を要する問題に発展する可能性があります。
狭いフィルターと制限を使って制御しながら再開する
現在の状態を保存した後、空または使用率の低いブロックグループを対象とする、最もリスクの低いフィルターから開始します。1回の実行で処理するチャンク数を制限し、範囲を広げる前に各結果を確認できるようにします。
使用率のしきい値は段階的に引き上げ、データとメタデータは分けて扱います。メタデータの再配置では多数の追加更新が発生する可能性があるため、平均使用率が低く見えるという理由だけで積極的にコンパクト化する必要はありません。
プロセスを強制終了するのではなく、対応しているバランス制御を使って一時停止、再開、キャンセルを行います。現在のブロックグループが完了したことと、保存されたバランス状態が次の操作と一致していることを確認してください。
バランス処理後の分散状態と容量を確認する
制御したバランス処理の前後で、デバイスごとの割り当て、データとメタデータのプロファイル、未割り当ての作業領域、ファイルシステム使用状況、再配置されたチャンク数を比較します。
成功した結果は、すべてのドライブでバイト使用量が完全に均等になることとは限りません。Linuxカーネルの概要では、統合されたマルチデバイス対応とオンラインサイズ変更が説明されています。そのため、最終的には有効なプロファイル、利用可能な割り当て容量、デバイスの健全性、将来の書き込みに十分な作業領域を確認してください。
バランス処理が完了するか、意図したフィルター範囲に到達し、大容量デバイスに新しい割り当てが行われ、空きチャンク作業領域が回復し、通常の書き込み、スナップショット、スクラブ、再起動が、バランス処理の予期しない再開なしに動作すれば、問題は解決しています。
サポートとヒント
もっと読む

Plexは別のDockerコンテナとGPUを共有できますか?
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。

Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。

Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。

