どの共有フォルダーが予期せぬNASの容量を消費していますか？

予期しないNASの容量を消費しているフォルダーは、ファイルブラウザで表示される最大のフォルダーとは限りません。

マウントされたファイルシステムから調査を始め、ディレクトリを一段階ずつ絞り込んでいきましょう。これにより、スナップショット、ゴミ箱、アプリケーションデータ、削除済みファイル、またはinodeの圧迫が最初に開いたビューの外側で容量を使用している場合に、見えている共有フォルダーを誤って責めることを防げます。

フォルダー名ではなくファイルシステムから始める

影響を受けている共有フォルダーを支えるファイルシステムを確認し、その使用済み容量、空き容量、inodeの値を記録します。dfコマンドの表示はファイルシステムレベルの合計を報告しますが、共有フォルダーのブラウザは見えてカウントできるオブジェクトのみを報告します。

共有パスとそのマウントポイントを照合してください。バインドマウント、コンテナボリューム、またはデータプールのマウントが欠落していると、馴染みのあるパスが意図したストレージプールではなく、より小さいシステムパーティションに書き込まれることがあります。

共有フォルダーを割り当て容量でランク付けする

同じファイルシステム上で、データプールのルートで深さ1のディレクトリ集計を実行します。目的は最上位のディレクトリを容量順に並べることであり、最大の結果をさらに掘り下げていきます。成長がプロジェクト、ユーザー、メディアライブラリ、バックアップセット、またはアプリケーションパスに結びつくまで繰り返します。

容量の質問には割り当てサイズを使いましょう。見かけのファイルサイズはファイルシステムのブロック、スパースファイル、ハードリンク、圧縮、重複排除の影響で異なることがあり、デスクトップのファイルマネージャーの表示とNASの割り当てが一致しない場合があります。

スナップショット、ゴミ箱、隠れた消費者を確認する

見えるフォルダーの合計がボリューム使用量より少ない場合は、スナップショットの保持、共有ゴミ箱、パッケージデータ、コンテナボリューム、サムネイル、一時アップロード領域、バックアップのバージョン履歴を調査してください。これらの消費者は共有ルートの外にある場合がありますが、それらを作成したワークロードはその共有に属しています。

大きなログファイルは、プロセスが書き込みを続けている間にリンクが解除されていることもあります。その場合、削除されたファイルがまだ開かれているため、ファイルシステムではカウントされ続けますが、ディレクトリの合計からは消えます。また、書き込みが失敗してもギガバイト単位の空きがある場合は、多数の小さなファイルによるinode枯渇も確認してください。

安全に削除できるものを確認する

最初に見つけた大きなディレクトリをすぐに削除しないでください。所有者、アクティブなプロセス、保持ルール、バックアップ状況を特定しましょう。ファイルシステムやNASのインターフェースを通じてスナップショットを整理し、ログは所有サービスでローテーションし、イメージやデータベースを削除する前にコンテナボリュームを確認してください。

各制御された変更の後、同じファイルシステムとディレクトリの測定を再実行します。クリーンな結果とは単に空き容量が増えることではなく、成長の原因が記録され、安全な保持判断がなされ、次の増加を可視化するアラートやクォータが設定されていることを意味します。

よくある質問

なぜ共有フォルダーの合計がボリューム使用量と一致しないのですか？

測定範囲が異なるためです。ボリュームはファイルシステムのメタデータや隠れた消費者を含みますが、フォルダーの合計はそのパス以下の到達可能なファイルのみを含み、見かけのサイズを報告することがあります。

大きなフォルダーがなくても多数の小さなファイルが容量を消費することはありますか？

はい。小さなファイルは割り当てブロックとinodeを消費します。キャッシュやメールスタイルのディレクトリは、単一のファイルが大きくなくてもファイルレコードを枯渇させることがあります。

なぜファイルを削除してもすぐにNASの空き容量が増えないのですか？

スナップショットがまだブロックを参照しているか、ゴミ箱がファイルを保持しているか、実行中のプロセスが削除済みファイルを開いたままにしている可能性があります。サービスの再起動や保持の整理を行う前に、どの状況かを特定してください。