317

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

その場合どうするのが正しいのでしょうか？

ディスク スペースの使用量が少ないディスク ドライブが、ディスク スペースの使用量が多いディスク ドライブよりも I ノードの使用量が多い可能性があるのはなぜですか?

大量のファイルを圧縮すると、使用inode回数が減る可能性はありますか?

4

18 に答える 18

230

運が悪ければ、すべての inode の約 100% を使用していて、scipt を作成できません。で確認できますdf -ih。

次に、この bash コマンドが役立つ場合があります。

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

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

于 2012-02-22T00:22:45.557 に答える
185

ディスクが満杯でない場合でも、ディスクに多数の inode が使用されるのは非常に簡単です。

i ノードはファイルに割り当てられるため、膨大な数のファイルがあり、それぞれがすべて 1 バイトである場合、ディスクがなくなるずっと前に inode が不足してしまいます。

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

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

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

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

ところで、大量のファイルを含むディレクトリを探している場合は、次のスクリプトが役立ちます。

#!/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_$$
于 2009-03-17T06:22:42.797 に答える
77

私の状況は、iノードが不足していて、できる限りすべてをすでに削除していたというものでした。

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

私はubuntu 12.04LTSを使用していますが、パッケージが見つからないためにaptが壊れていたため、約400,000のinodeを占有していた古いLinuxカーネルを削除できませんでした。また、inode が不足していたため、新しいパッケージをインストールできず、立ち往生していました。

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

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

これで、不足しているパッケージをインストールして apt を修正するのに十分でした

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

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

$ sudo apt-get autoremove

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

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361 434719   54% /
于 2015-11-06T08:46:37.380 に答える
58

私の解決策：

これが 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

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

于 2014-12-12T16:56:45.697 に答える
2

これは、HostGator アカウント (すべてのホスティングに inode 制限を設定している) で、スパム攻撃後に発生しました。/root/.cpanel/comet に膨大な数のキュー レコードが残っていました。これが発生し、空いている inode がないことがわかった場合は、シェルから次の cpanel ユーティリティを実行できます。

/usr/local/cpanel/bin/purge_dead_comet_files
于 2014-11-12T08:37:19.307 に答える
1

前に述べたように、小さなファイルがたくさんある場合、ファイルシステムは inode を使い果たす可能性があります。ここで、ほとんどのファイルを含むディレクトリを見つける手段をいくつか提供しました。

于 2016-08-17T18:07:08.513 に答える
1

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

rm -rf /var/cache/eaccelerator/*

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

于 2013-04-01T20:17:45.390 に答える
1

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

ここで間違っている場合は修正してください。

于 2016-04-01T07:01:07.020 に答える