「組み込みストレージがほぼ満杯」という症状は、単一のZimaOSバグではありません。このスレッドの情報から、少なくとも3つの異なる原因が明らかになりました。USBの保存先が消失し、実質的にローカルの下に再作成されたバックアップタスク、成長していた519 GBの暴走Docker JSONログ、そして別のシステムでは、 /DATA、519 GBまで増大した暴走Docker JSONログ、そして別のシステムでは、 /DATA/.media 409 GBを消費していました。
最も安全な対応は、まず容量を測定し、書き込み元のサービスを特定して停止し、確認できたデータだけを削除することです。/DATA/.docker、.media、またはAppDataが大きいというだけの理由で、再帰的に削除しないでください。
/DATA 大容量データプールに数TBの空きが残っていたにもかかわらず、アプリデータを移行しても、今後のすべての書き込みが/dataから出ていくとは限りません
読み取り専用のduチェックを使って最大のディレクトリを特定する
元のユーザーは次の内容を共有しました。
sudo du -x -h --max-depth=1 /DATA 2>/dev/null | sort -hrこれはファイルを変更しません。疑わしいディレクトリに対して繰り返し実行し、最大のサブツリーを絞り込んでください。
接続解除されたバックアップ先が、最初に確認された原因でした
Cobblerkidは、バックアップタスクが外付けUSBドライブを想定していたことを突き止めました。ドライブを取り外した後、バックアップ構造が /DATA そして、スケジュールされたジョブはローカルストレージがいっぱいになるまで書き込みを続けていました。
Zima-Jerryは、これは問題のようだと認め、社内に報告しました。つまり、単なるコミュニティ内の推測ではありません。
別のユーザーが519 GBのコンテナJSONログを発見
2人目の参加者は、あるDockerコンテナのディレクトリを調べ、519 GBの *-json.log Home Assistantコンテナによるものと見られる、約519 GBのファイル。
そのユーザーはコンテナを削除して容量を回復しました。ただし、これを「Dockerログを手動で削除する」と一般化してはいけません。まずログを大量に出力しているコンテナを特定し、ログを生成している繰り返しエラーを調べて修正してください。
別のシステムでは、/DATA/.media配下が409 GBに達していた
別のユーザーは、通常のAppDataが約225 GBだったという容量の内訳を投稿しました。 .docker わずか3.5 GBでしたが、 .media 409 GBを消費していました。これは、「ディスク容量不足」の報告すべてを1つのクリーンアップコマンドで解決できない理由を示しています。
現在のZimaOSでは、アプリストレージとキャッシュの制御項目が増えています
IceWhaleの現行ドキュメントによると、「設定」→「アプリ」でアプリデータの保存場所を確認し、アプリごとの使用量を確認してキャッシュをクリーンアップできます。AppDataをメインストレージアレイに保持すると、小容量のシステムドライブへの負荷を軽減できます。
シェルでのクリーンアップを試みる前に、現在のZimaOSアプリストレージ管理機能を使用してください。
より安全な復旧手順
- データを生成し続けているタスク／アプリを停止する。
- 測定する
/DATA読み取り専用 - 対象の正確なファイル／フォルダーと所有者を特定する。
- 重要なAppData／設定をバックアップする。
- 可能な限り、サポートされているアプリ／キャッシュの管理機能を使用する。
- 使い捨てのデータ、または誤りであることを確認したデータだけを削除する。
- 再起動後も空き容量が安定していることを確認する。
docker image pruneでは、Dockerのあらゆる容量問題は解決できない
ソースでは、raller1028が言及しています docker image prune -a コンテナで使用されていないイメージを削除する方法として。未使用のイメージレイヤーを回収できますが、519GBのアクティブなコンテナJSONログ、暴走したバックアップ先、またはユーザーデータは解決できません。 .media.
サイズスキャンを使って、まずカテゴリを特定してください。間違ったカテゴリを対象にしたクリーンアップコマンドでは、ほとんど容量を解放できない一方で、新たなリスクが生じる可能性があります。
巨大なJSONログは、コンテナのエラーループが依然として問題であることを示す
問題のあるコンテナを削除することで、あるユーザーは容量を解放できました。しかし、より重要な長期的課題は、なぜアプリケーションが数百GBものログを書き込んだのかという点です。同じワークロードを再インストールする前に、最近のログを調べて、繰り返し発生するエラー、再起動ループ、利用できないデバイス、設定上の問題がないか確認してください。
再作成したコンテナが直ちにログの生成を再開すると、ディスク容量不足の状態が再発します。
.mediaは使い捨てのキャッシュではなく、管理対象ストレージとして扱う
409 GBの /DATA/.media この例には、一時キャッシュではなく、実際の管理対象マウント／ファイルデータが含まれている可能性があります。そこにあるものを削除する前に、どのストレージ／共有／アプリが所有しているかを特定し、同じファイルが別の場所にも存在することを確認してください。
内蔵ストレージ容量不足に関するFAQ
ソースはAppDataの移行自体が失敗したことを証明していますか？
いいえ。元の投稿者は管理対象カテゴリを移行しており、確認された容量不足は接続されていないバックアップ先が原因でした。
.dockerディレクトリ全体を削除しても安全ですか？
いいえ。アクティブなコンテナの状態、ログ、イメージ、アプリケーションの依存関係が含まれている可能性があります。
ソースに基づく最初の最適なコマンドは何ですか？
読み取り専用の du のサイズスキャン /DATA 実際の大きなサブツリーを特定するため。
