この事例は、ZimaOSのシステムディスクが完全に満杯になると、基盤となるRAIDやユーザーデータを必ずしも破壊することなく、移行がフリーズしたように見えることを示しています。ZimaCubeの228 GBシステムSSDは、Resilio関連のインデックス作成データやアプリケーションデータがOSドライブ上で増加した結果、空き容量0 Bになりました。SMBとFinderからのアクセスは引き続き機能していましたが、ダッシュボードは不安定になり、移行は最初5%で止まったように見えました。
その後、移行は45%、49%と進み、最終的には1日以上経過した後に完了しました。投稿者は後に、Resilioがシステムディスクへのインデックス作成や書き込みを続けないよう停止したとも述べています。現在のZimaOSドキュメントでは、AppDataをシステムドライブに置かないことが明確に推奨されています。
システムSSDが完全に満杯になっていた
アプリデータの移行は最初、5%で止まったように見えた
進行が遅いからといって、移行が完全に停止したとは限らない
その後、ユーザーは一晩のうちに移行が45%、さらに49%まで進んだことを確認しました。数か月後、最終的には1日以上かかったと考えられるものの、移行が完了したと報告しています。
現在のIceWhaleのガイダンスでは、AppDataでシステムドライブを満杯にしないよう明確に警告している
現在のApp Storage Pathsガイダンスでは、アプリケーションデータベース、サムネイル、メタデータなどのAppDataによって小容量のシステムドライブが満杯になり、アップデートやアプリケーション、さらにはデバイス自体が異常な動作をする可能性があると説明されています。
現在のAppDataストレージガイダンスを確認してください。
ディスクを埋め続けているアプリケーションを停止する
Resilio、LLMモデル、Immichのキャッシュ、その他のコンテナが空けた容量をすぐに書き戻すなら、数GBの空き容量を作っても意味がありません。システムストレージを消費しているアプリを特定し、移行を再試行する前に停止してください。
移行を再試行する前に作業用の空き容量を確保する
移行処理には、データベース、一時状態、ログ、アプリケーション処理のための容量が必要です。削除または移動するのは、内容を確実に特定できたデータだけにしてください。不明なシステムディレクトリに対して、ルートレベルで広範囲なクリーンアップを実行しないでください。
システムが安定したら、現在のデータ移行ツールを使用する
現在のZimaOSでは、設定 > データ移行から、Dockerイメージ、Dockerアプリケーションデータ、管理対象のユーザーデータベースをストレージ領域間で移動できます。
現在のデータ移行ワークフローを参照してください。
膨大な数の小さなファイルは、合計容量から想像するより遅くなることがある
インデックスデータベース、サムネイル、メタデータのディレクトリでは、大きなメディアファイルよりも、1GBあたりに必要なファイルシステム操作がはるかに多くなる場合があります。
移行中に稼働中のAppDataを手動で移動しない
後から参加したユーザーが、移行がすでに停止している状態でLLMのAppDataフォルダーを手動で移動しました。その結果、アプリケーションの設定パス、ZimaOSの移行状態、実際のファイルシステム上の場所が一致しなくなる可能性があります。
この事例では、Resilioのファイル名に関する別の問題も報告されていた
数か月後、timothyは、Resilioがサポートされていない文字を含むファイル名を変更したため、ZimaOS上でファイルが見つからないように見えたと述べました。さらに、ZimaOSがファイルを失ったという以前の推測を明確に訂正しました。
ダッシュボードが壊れていても、ストレージプールが失われたとは限らない
この事例では、ダッシュボードからログアウトされ、移行UIの動作も不安定になっている間、SMBとFinderは引き続き使用できました。この違いは重要です。システムディスクが満杯になると、制御プレーンのサービスが停止することがありますが、分離されたデータアレイはマウントされたまま読み取り可能な場合があります。
破壊的なRAID操作や再インストールを行う前に、その証拠を保全してください。
別の移行を開始する前にシステムディスクをトリアージする
システムドライブの容量を消費しているディレクトリを確認し、所有するアプリケーションを特定して、書き込み元を停止してください。アプリを安全に削除して再作成できる場合は、不用意にディレクトリを削除するのではなく、サポートされている操作で不要なキャッシュやイメージデータを削除してください。
作業用の空き容量を確保したら、必要に応じて影響を受けたサービスやアプリだけを再起動し、移行前に空き容量が安定して維持されることを確認してください。
現在の移行は全画面の管理対象操作になっている
現在のIceWhaleドキュメントでは、データ移行の実行中は他の操作を利用できないと説明されています。データを移動するアプリケーションについては停止時間を計画し、手動での同時移動を避け、同じフォルダーを変更する前に移行が明確な完了またはエラー状態に到達するまで待ってください。
再インストールは最後の手段であり、空き容量0 Bへの最初の対応ではない
ユーザーデータとストレージが正常なら、システム領域を解放してAppDataの移行を完了することで、NASを再構築せずにシステムを復旧できる場合があります。再インストールが必要になった場合は、まずアプリケーションデータ、ストレージメタデータ、重要なファイルをバックアップし、最新の復旧・再インストールガイダンスに従ってください。
システムディスクが満杯になった場合のFAQ
この事例の移行は最終的に完了しましたか？
はい。投稿者は後に、1日以上かかったものの完了したと述べています。
移行の進捗バーが5%で止まっているだけで、データが失われたことになりますか？
いいえ。この事例では後に進行し、SMBとRAIDも引き続きアクセス可能でした。
ZimaOS-HDが満杯になった場合、現在のユーザーはまず何をすべきですか？
書き込みを続けているアプリを停止し、安全に空き容量を確保してから、不明なシステムファイルを削除するのではなく、現在のデータ移行およびAppDataの管理機能を使用してください。
