なぜNASは大きなファイルを削除しても空き容量が回復しないのですか？

大きなファイルが消えた後にNASが空き容量を回復しないのは、表示されている名前を削除することがストレージ回収の一部に過ぎないためです。ごみ箱、ファイルシステムのスナップショット、バックアップバージョン、または実行中のプロセスがファイルの基になるブロックをまだ保持している可能性があります。

適切な修正は、どこがまだそのブロックを参照しているかによります。共有、スナップショットレイヤー、実行中のサービス、プールの順に確認してください。どのレイヤーが失われたスペースを所有しているか特定する前に、すべてのスナップショットを削除したりNAS全体を再起動したりしないでください。

根本原因：ファイルは消えたが、そのブロックはまだ参照されている

ファイルには表示されるディレクトリエントリとそのデータを含むストレージブロックがあります。エントリを削除するとフォルダからファイルは消えますが、ファイルシステムは残っているすべての参照が解放されて初めてそのブロックを再利用できます。この違いが、削除が成功しても必ずしも空き容量が同じだけ増えない理由を説明します。

LinuxベースのNASでは、サービスがすでに削除されたファイルを開いたままにしていることがあります。カーネルは最終的なファイルディスクリプタが閉じられるまでデータを保持しますが、ファイルブラウザや通常のディレクトリスキャンではそれを確認できません。Red Hatの削除ファイルのスペース保持に関する説明は、保持しているプロセスを停止または正常に再起動することで、削除だけでは解放されなかったスペースが解放される理由を示しています。

他のホルダーはオープンファイルレイヤーの上で動作します。ネットワークリサイクルサービスはファイルをアンリンクせずに移動することがあり、コピーオンライトスナップショットは回復のために古いブロックを意図的に保持します。見た目の結果は似ています—ほとんどまたはまったく容量が回復しません—しかし安全な修正アクションは異なります。

どのNASレイヤーがまだ削除されたデータを保持しているか？

削除後に何が変わったかを比較することから始めます。ファイル名が隠しごみ箱ディレクトリに移動しているかもしれませんし、ライブデータセットが縮小する一方でスナップショットの使用量が増えているかもしれません。または、プールの合計がディレクトリツールでカウントできるファイルよりも高いままかもしれません。これらのパターンは破壊的なクリーンアップを行わずにスペースホルダーを絞り込むのに役立ちます。

ごみ箱は最も単純なケースです。SambaのVFS recycle-binの動作は削除要求を傍受し、ファイルをすぐに削除するのではなくリポジトリに移動します。SMB共有を通じて削除されたファイルは、元のフォルダから消えていても同じストレージプールに残ることがあります。

スナップショットは、ライブディレクトリに別の通常ファイルを保持せずにブロックを保存できるため、わかりにくいです。スナップショットが削除前の状態を参照している場合、ライブファイルを削除しても現在の参照のみが削除されます。このスナップショットのスペース会計例は、他のスナップショットが同じブロックを参照している場合、1つのスナップショットで回収できるスペースが少ない理由を示しています。

プールと共有の値は異なる範囲を測定することもあります。共有はそのデータセットやクォータを報告する場合がありますが、ストレージダッシュボードには子データセット、アプリケーションデータ、バックアップバージョン、予約、およびスナップショット保持ブロックが含まれます。削除が失敗したと結論付ける前に、同じ範囲同士で比較してください。

回収履歴を破壊せずにスペースを回収する

回収は可逆的なチェックから永久削除へ移行すべきです。まず容量ビューを更新し、正しいプール、データセット、および共有を読み取っていることを確認してください。短時間の会計遅延は正常ですが、アクティビティが落ち着いた後も持続するギャップは、別の参照またはストレージ範囲の調査が必要であることを示します。

1. 削除されたファイルが元の共有に存在せず、アプリケーションによって移動または名前変更されていないことを確認します。
2. 該当する共有およびユーザーアカウントに関連付けられたごみ箱を調査します。
3. スナップショットとバックアップの保持状況を日付、データセット、および推定回収可能なスペースで確認します。
4. ファイルシステムの使用量を表示されているディレクトリの合計と比較して、隠れた割り当てを特定します。
5. プールを変更する前に、子データセット、アプリケーションボリューム、クォータ、および予約を確認してください。
6. 確認された保持者は、その通常の保持、サービス、または管理者の制御を通じて解放してください。

ファイルシステムの使用量が目に見えるディレクトリ合計より高い場合は、まだ開かれている削除済みファイルを調査してください。lsofのオープンファイルチェックはlsof +L1を使ってディレクトリリンクが残っていないファイルをリストアップします。プロセスを特定し、通常のリロードまたは優雅な再起動手順を使ってください。空き容量回復のためだけに不明なデータベースやストレージサービスを終了しないでください。

スナップショットで保持されているデータについては、回復ポイントを削除する前に各保持変更で実際に回収できる容量を見積もってください。複数のスナップショットで共有されているブロックは、最後の参照スナップショットが期限切れになるまで割り当てられたままになるため、1つのスナップショットを削除しても見かけ上の履歴サイズほどの空き容量は戻らないことがあります。まず回復価値を保持し、保持期間を慎重に調整してください。

定期的な削除でプールが満杯に近づく場合、問題は容量計画にもあります。ごみ箱の保持、スナップショット、アプリケーション、バックアップ履歴はライブファイルサイズを超える余裕が必要なので、使えるNAS容量の計画にはこれらの目に見えにくい消費も含める必要があります。

よくある質問

なぜNASのごみ箱を空にしても空き容量の一部しか回復しなかったのですか？

同じブロックがスナップショット、バックアップバージョン、または開かれているプロセスによってまだ参照されている可能性があります。ごみ箱を空にするのはその保持者だけを削除するもので、他の参照を上書きしたり、別のデータセットによって予約された空き容量を解放したりするわけではありません。

NASが新たに解放された空き容量を表示するのにどれくらい時間がかかりますか？

ストレージの会計処理やバックグラウンド作業が落ち着くまでの短い遅延は正常です。ダッシュボードやファイルシステムの統計を更新しても値が変わらない場合は、スナップショット、削除されたまま開かれているファイル、クォータ、表示されている数値が共有かプール全体かを確認してください。

RAIDは削除されたファイルの空き容量解放を防ぎますか？

RAIDは通常、アクティブなアレイ全体に削除を適用します。古いファイルを回復履歴として保持することはありません。ごみ箱やスナップショットは別のレイヤーであり、RAID保護の制限は、削除されたファイルの回復や空き容量の保持ではなく、可用性に関するものです。