iノードの使用を解放する方法？

iノードの使用率が100％（df -iコマンドを使用）のディスクドライブがあります。ただし、ファイルを大幅に削除した後も、使用率は100％のままです。

それを行う正しい方法は何ですか？

ディスクスペースの使用率が低いディスクドライブが、ディスクスペースの使用率が高いディスクドライブよりもInodeの使用率が高くなる可能性があるのはなぜですか。

多くのファイルを圧縮すると、使用されるiノード数が減る可能性はありますか？

ディスクがいっぱいになっていなくても、ディスクで多数のiノードを使用するのは非常に簡単です。

iノードはファイルに割り当てられるので、億単位のファイルがあり、すべて1バイトの場合、ディスクが不足する前にiノードが不足します。

ファイルに複数のハードリンクがある場合、ファイルを削除してもiノード数が減らない可能性もあります。すでに述べたように、iノードはディレクトリエントリではなくファイルに属しています。ファイルに2つのディレクトリエントリがリンクされている場合、1つを削除してもiノードは解放されません。

さらに、ディレクトリエントリを削除することもできますが、実行中のプロセスがまだファイルを開いている場合は、iノードは解放されません。

私の最初のアドバイスは、すべてのファイルを削除してからボックスを再起動して、ファイルを開いたままのプロセスが残っていないことを確認することです。

それでも問題が解決しない場合は、お知らせください。

ちなみに、多くのファイルを含むディレクトリを探している場合、このスクリプトが役立つことがあります。

#!/bin/bash
# count_em - count files in all subdirectories under current directory.
echo 'echo $(ls -a "$1" | wc -l) $1' >/tmp/count_em_$$
chmod 700 /tmp/count_em_$$
find . -mount -type d -print0 | xargs -0 -n1 /tmp/count_em_$$ | sort -n
rm -f /tmp/count_em_$$

非常に運が悪い場合は、すべてのiノードの約100％を使用しており、sciptを作成できません。これはで確認できdf -ihます。

次に、このbashコマンドが役立ちます。

sudo find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n

はい、これには時間がかかりますが、ファイルが最も多いディレクトリを見つけることができます。

私の状況では、iノードがなくなり、できることはすべて削除してしまいました。

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361     11  100% /

私はubuntu 12.04LTSを使用していて、パッケージが見つからないためにaptが壊れたため、約400,000のiノードを使用していた古いLinuxカーネルを削除できませんでした。そして、iノードが足りなくなってスタックしてしまったため、新しいパッケージをインストールできませんでした。

いくつかの古いLinuxカーネルを手動で削除して、約10,000のiノードを解放しました

$ sudo rm -rf /usr/src/linux-headers-3.2.0-2*

これで、不足しているパッケージをインストールしてaptを修正できました

$ sudo apt-get install linux-headers-3.2.0-76-generic-pae

そしてaptで残りの古いLinuxカーネルを削除します

$ sudo apt-get autoremove

物事は今ずっと良くなっています

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361 434719   54% /

私の解決策：

これが次のiノードの問題かどうかを確認してください。

df -ih

iノード数が多いルートフォルダを見つけてください。

for i in /*; do echo $i; find $i |wc -l; done

特定のフォルダを検索してみてください：

for i in /src/*; do echo $i; find $i |wc -l; done

これがLinuxヘッダーの場合、最も古いものを削除してみてください：

sudo apt-get autoremove linux-headers-3.13.0-24

個人的には、それらをマウントされたフォルダーに移動し（最後のコマンドが失敗したため）、最新のものをインストールしました：

sudo apt-get autoremove -f

これは私の問題を解決しました。

私は同じ問題を抱えていました、phpのディレクトリセッションを削除して修正しました

rm -rf /var/lib/php/sessions/

/var/lib/php5古いバージョンのphpを使用している場合は、下にある可能性があります。

次の権限で再作成してください

mkdir /var/lib/php/sessions/ && chmod 1733 /var/lib/php/sessions/

Debianのディレクトリのデフォルトのパーミッションが表示されましたdrwx-wx-wt（1733）

スパム攻撃の後に、HostGatorアカウント（すべてのホスティングにiノード制限を設定）でこれを経験しました。/root/.cpanel/cometに膨大な数のキューレコードを残しました。これが発生し、空きiノードがない場合は、シェルを介してこのcpanelユーティリティを実行できます。

/usr/local/cpanel/bin/purge_dead_comet_files

RSYNCを使用して多数のファイルを削除できます

rsync -a --delete blanktest/ test/

0個のファイルが入ったblanktestフォルダーを作成します。コマンドを実行すると、テストフォルダーが多数のファイルと同期されます（この方法を使用して5M近くのファイルを削除しました）。

http://www.slashroot.in/which-is-the-fastest-method-to-delete-files-in-linuxのおかげで

PHPをブロックにコンパイルするため、eacceleratorが問題を引き起こしている可能性があります...負荷の高いサイトのAmazon AWSサーバーでこの問題が発生しました。問題が解決しない場合は、/ var / cache / eacceleratorのeacceleratorキャッシュを削除して、iノードを解放します。

rm -rf /var/cache/eaccelerator/*

（または何でもあなたのキャッシュディレクトリ）

最近、同様の問題に直面しました。プロセスが削除されたファイルを参照する場合、iノードは解放されないため、lsof /を確認する必要があります。プロセスを強制終了/再起動すると、iノードが解放されます。

ここで間違っていれば訂正してください。

以前に述べたように、小さなファイルがたくさんある場合、ファイルシステムはiノードを使い果たすかもしれません。私はここにほとんどのファイルを含むディレクトリを見つけるいくつかの手段を提供しました。

遅い答え：私の場合、それは私のセッションファイルでした

/var/lib/php/sessions

Inodesを使用していた。
私は自分のcrontabを開くことも、削除操作をトリガーするだけでなく、新しいディレクトリを作成することもできませんでした。私はPHPを使用しているため、このガイドでは、例1からコードをコピーし、cronjobを設定してコードのその部分を実行します。

<?php
// Note: This script should be executed by the same user of web server 
process.

// Need active session to initialize session data storage access.
session_start();

// Executes GC immediately
session_gc();

// Clean up session ID created by session_gc()
session_destroy();
?>

私がどうやって私のcrontabを開いたのか疑問に思っているのなら、CLIを使用して一部のセッションを手動で削除しました。

お役に立てれば！

あなたはこの情報を見ることができました

for i in /var/run/*;do echo -n "$i "; find $i| wc -l;done | column -t

これまでのところこれに対する多くの答えと上記のすべてが具体的であるように見えます。使用することで安全になると思いますstatが、OSによっては、inodeエラーが発生する場合があります。したがって、オーバーフローの問題を回避するためにstatを使用64bitして独自の呼び出し機能を実装することは、かなり互換性があるようです。

dockerを使用している場合は、すべての画像を削除します。彼らは多くのスペースを使いました...

すべてのコンテナを停止します

docker stop $(docker ps -a -q)

すべてのコンテナを削除

docker rm $(docker ps -a -q)

すべての画像を削除

docker rmi $(docker images -q)

私に働きます