開いたままになっている削除済みファイルからディスク領域を解放する最良の方法

こんにちは私は削除された多くのファイルを持っていますが、何らかの理由で、削除されたファイルに関連付けられたディスクスペースは、ディスクスペースを取得しているファイルのプロセスを明示的に終了するまで利用できません

$ lsof /tmp/
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF      NODE NAME
cron     1623 root    5u   REG   0,21        0 395919638 /tmp/tmpfPagTZ4 (deleted)

上記の削除されたファイルによって占有されるディスク容量は、タブキーを使用してファイルパスをオートコンプリートしようとするとエラーが発生するなどの問題を引き起こします bash: cannot create temp file for here-document: No space left on device

しかし、実行しkill -9 1623た後、そのPIDのスペースが解放され、エラーが発生しなくなりました。

私の質問は：

• ファイルが最初に削除されたときにこのスペースがすぐに解放されないのはなぜですか？
• 削除されたファイルに関連付けられたファイルスペースを取り戻すための最良の方法は何ですか？

また、私が使用した誤った用語や、この状況に関するその他の関連情報および関連情報をお知らせください。

ユニックスでは、ファイル名は、ファイルが存在するメモリ（ハードドライブまたはRAMに裏打ちされたファイルシステムでさえある）を指す単なるポインタ（inode）です。各ファイルはそれへのリンクの数を記録します：リンクはファイル名（複数の、同じファイルへの複数のハードリンクがある場合）またはファイルが開かれるたびに、プロセスは実際に「リンク」を保持します同じスペース。

スペースが物理的に解放されるのは、リンクが残っていない場合のみです（したがって、そこに到達することは不可能です）。それが唯一の賢明な選択です：ファイルが使用されている間、他の誰かがそれにアクセスできなくても重要ではありません：あなたはそれを使用していて、それを閉じるまで、あなたはまだそれを制御できます-あなたはファイル名にさえ気付かないでしょうなくなったり移動したりします これは一時ファイルにも使用されます。一部の実装ではファイルを作成してすぐにリンクを解除するため、ファイルシステムには表示されませんが、ファイルを作成したプロセスは通常それを使用しています。Flashプラグインは特にこの方法を好みます。ダウンロードされたすべてのビデオファイルは開いたままですが、ファイルシステムには表示されません。

答えは、プロセスがファイルを開いたままにしている間、スペースを取り戻すことを期待すべきではないということです。解放されず、積極的に使用されています。これは、アプリケーションがファイルの使用を終了したら、実際にファイルを閉じる必要がある理由の1つでもあります。通常の使用法では、そのスペースを無料と考えるべきではありません。また、これはあまり一般的ではありません-意図的にリンクされていない一時ファイルを除いて、実際にファイルが存在することはありません使用されていないが、まだ開いていることを検討してください。これを頻繁に行うプロセスがあるかどうかを確認して、それをどのように使用するかを検討するか、単にスペースを増やしてください。

このiノードへの参照が削除されるファイルシステムからファイルが削除されます。参照はディスク上（任意のディレクトリ内のリンク）にあり、開いているアプリケーションからでも可能です。ファイルを削除すると、ディスクからの参照のみが削除されますが、アプリケーションからの参照は引き続き存在します。

次に、2つの方法でスペースを「解放」できます。

1. 前述のように、ファイルを開くアプリケーションを強制終了できます。
2. 次のことができます...ファイルを切り捨てます。削除された場合でも：

pidを知っている場合-このpidで開いているファイルを確認してください：ls -l / proc / PID / fd

undefine @ uml：〜$ ls -l / proc / 18596 / fd
razem 0
lrwx ------ 1 undefine undefine 64 lut 1 00:06 0-> / dev / pts / 30
lrwx ------ 1 undefine undefine 64 lut 1 00:06 1-> / dev / pts / 30
lrwx ------ 1 undefine undefine 64 lut 1 00:05 2-> / dev / pts / 30
lr-x ------ 1 undefine undefine 64 lut 1 00:06 3-> / home / undefine / x（削除済み）
lr-x ------ 1 undefine undefine 64 lut 1 00:06 4-> anon_inode：inotify

ご覧のとおり-3 fdが削除されます。コマンドでそれを切り捨てることができます（たとえば）：

undefine @ uml：〜$：> / proc / 18596 / fd / 3
undefine @ uml：〜$ 

アプリケーションがこのファイルから読み取った場合、それは彼らにとって危険である可能性があることに注意してください。ただし、ログファイルのみの場合は、安全に切り捨てることができます。

他の人が言ったlsofように、開いているファイル記述子のためにディスク上に残っているすべての削除されたファイルをリストするために使用することができます。ただし、これは非常に長いリストになる場合があります。以下は、これらのファイルをバイト単位の昇順でソートしてリストするコマンドです。

sudo lsof -F sn0 | tr -d '\000' | grep deleted | sed 's/^[a-z]*\([0-9]*\)n/\1 /' | sort -n

これを行うためのより簡潔な方法があるかもしれませんが、上記のコマンドは私のために働いた。

実行中のプロセスには、削除されたばかりのファイルへのファイルハンドルが開いているため、スペースはすぐには解放されません。結局のところ、プロセスがまだファイルを使用しようとしている場合、おそらくカーネルにそのファイル（ファイル）を削除させたくないでしょう。それはプロセスを少し混乱させるかもしれません。スペースを解放するための最善の（そして唯一の方法としては）方法は、あなたがやったことをすることです-プロセスを強制終了します。

（ミント17.1）

TL; DR：

• sudo baobab（Disk Usage Analyzer）で検査します。
• rootユーザーのゴミ箱をクリアします。

コンテキスト

絶えずファイルを削除している間、スペースの減少に追われていました。trash-cliゴミ箱を空にするためにパッケージをインストールしましたが、これは役に立ちませんでした。最後に、baobabディスクスペース構造を検査するために（少なくともMint 17.1でGUIのディスク使用状況アナライザー）を実行すると、一部のフォルダーにアクセスできないという警告が表示されました。だから私はroot使用してそれを実行しましたsudo baobab。これにより問題が明らかになりました。削除されたファイルの多くは、root自分のユーザーではなく、ユーザーのゴミ箱にありました。したがって、スペースを解放できませんでした。その後、ルート（sudo trash-cli）としてゴミ箱を空にしただけで、すべてのスペースが返されました。

以下のコマンドを使用してみてください

lsof | grep deleted

削除されたファイルのPIDを強制終了します。