iノードが使用されている場所を見つける

そのため、ボックスの1つの監視システムから、ファイルシステム上の空きiノードの数が少なくなっているという警告を受け取りました。

df -i 出力はこれを示しています：

Filesystem       Inodes  IUsed    IFree IUse% Mounted on
/dev/xvda1       524288 422613   101675   81% /

ご覧のとおり、ルートパーティションの81％のiノードが使用されています。
それらはすべて単一のディレクトリで使用されていると思われます。しかし、それがどこにあるのかをどのようにして見つけることができますか？

この質問はstackoverflowで見ましたが、私は答えが好きではありませんでした、それは本当にU＆Lでここにあるべき質問です。

基本的に、ファイルシステム上の各ファイルに対してiノードが使用されます。したがって、一般に、iノードが不足すると、多数の小さなファイルが存在することになります。したがって、質問は「どのディレクトリに多数のファイルがあるか」ということになります。

この場合、重要なファイルシステムはルートファイルシステムな/ので、次のコマンドを使用できます。

find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n

これにより、ファイルシステム上のすべてのディレクトリのリストが、そのディレクトリ内のファイル（およびサブディレクトリ）の数が接頭辞としてダンプされます。したがって、ファイル数が最大のディレクトリが一番下になります。

私の場合、これにより次のことがわかります。

   1202 /usr/share/man/man1
   2714 /usr/share/man/man3
   2826 /var/lib/dpkg/info
 306588 /var/spool/postfix/maildrop

したがって、基本的に/var/spool/postfix/maildropはすべてのiノードを消費しています。

注意してください、この答えには3つの注意事項があります。パスに改行があるものは適切に処理されません。私は私のファイルシステムが改行とファイルがありません知っている、これが唯一の人間の消費のために使用されていることから、潜在的な問題を解決する価値はありません（と1は常に置き換えることができ\nて\0、使いsort -z以上）。また、ファイルが多数のディレクトリに分散している場合も処理しません。ただし、これは可能性が低いため、リスクは許容できると考えています。また、同じファイルへのハードリンクを数回（したがって、iノードを1つだけ使用して）数えます。繰り返しますが、偽陽性を与える可能性は低いです

私がstackoverflowの答えのどれも好きではなかった主な理由は、それらがすべてファイルシステムの境界を越えていることです。私の問題はルートファイルシステムにあったので、これはすべてのマウントされたファイルシステムを横断することを意味します。-xdevfindコマンドでスローしても、適切に機能しません。
たとえば、最も支持された答えは次のとおりです。

for i in `find . -type d `; do echo `ls -a $i | wc -l` $i; done | sort -n

代わりにこれを変更すると

for i in `find . -xdev -type d `; do echo `ls -a $i | wc -l` $i; done | sort -n

にもかかわらず/mnt/foo、マウントされ、それはまた、ルートファイルシステム上のディレクトリなので、中に上げるだろうfind . -mount -type dし、それはに渡されますよls -a $iマウントに飛び込むなります。

find私の答えでは、代わりに、マウント上のすべての単一のファイルのディレクトリを示しています。基本的に次のようなファイル構造を使用します。

/foo/bar
/foo/baz
/pop/tart

で終わる

/foo
/foo
/pop

したがって、重複行の数を数えるだけです。

これは、アスカーの要請により、ここから再投稿されます。

du --inodes -S | sort -rh | sed -n \
        '1,50{/^.\{71\}/s/^\(.\{30\}\).*\(.\{37\}\)$/\1...\2/;p}'

そして、あなたが同じファイルシステムにとどまりたい場合：

du --inodes -xS

出力例を次に示します。

15K     /usr/share/man/man3
4.0K    /usr/lib
3.6K    /usr/bin
2.4K    /usr/share/man/man1
1.9K    /usr/share/fonts/75dpi
...
519     /usr/lib/python2.7/site-packages/bzrlib
516     /usr/include/KDE
498     /usr/include/qt/QtCore
487     /usr/lib/modules/3.13.6-2-MANJARO/build/include/config
484     /usr/src/linux-3.12.14-2-MANJARO/include/config

今LSで：

何人かの人々は、彼らが最新のcoreutilsを持っていないと述べました、そして、-inodesオプションは彼らに利用できません。だから、ここにlsがあります：

ls ~/test -AiR1U | 
sed -rn '/^[./]/{h;n;};G;
    s|^ *([0-9][0-9]*)[^0-9][^/]*([~./].*):|\1:\2|p' | 
sort -t : -uk1.1,1n |
cut -d: -f2 | sort -V |
uniq -c |sort -rn | head -n10

好奇心が強い場合、その退屈なビットの心と魂は、再帰的な検索結果のそれぞれを、それが見つかったディレクトリ名でregex置き換えています。そこから、繰り返されるiノード番号を絞り込んでから、繰り返されるディレクトリ名をカウントし、それに応じてソートするだけです。filenamels's

この-Uオプションは、特にソートを行わず、代わりにディレクトリリストを元の順序で、つまりinode番号順に表示するという点で、ソートに特に役立ちます。

そしてもちろん-1、ファイル名に含まれる可能性のある改行や、リストを解析しようとするときに発生する可能性のある他の見苦しい問題に関係なく、1行につき1つの結果を保証するという点で非常に役立ちます。

そしてもちろん-A、すべてのために、そして-iiノードのために、そして-R再帰のために、それはそれの長短です。

これの基本的な方法は、lsのすべてのファイル名を、sedに含まれるディレクトリ名に置き換えることです。それに続いて...さて、私は少しあいまいです。ここでわかるように、ファイルを正確にカウントしていることはかなり確信しています。

% _ls_i ~/test
> 100 /home/mikeserv/test/realdir
>   2 /home/mikeserv/test
>   1 /home/mikeserv/test/linkdir

これにより、duコマンドとほとんど同じ結果が得られます。

DU：

15K     /usr/share/man/man3
4.0K    /usr/lib
3.6K    /usr/bin
2.4K    /usr/share/man/man1
1.9K    /usr/share/fonts/75dpi
1.9K    /usr/share/fonts/100dpi
1.9K    /usr/share/doc/arch-wiki-markdown
1.6K    /usr/share/fonts/TTF
1.6K    /usr/share/dolphin-emu/sys/GameSettings
1.6K    /usr/share/doc/efl/html

LS：

14686   /usr/share/man/man3:
4322    /usr/lib:
3653    /usr/bin:
2457    /usr/share/man/man1:
1897    /usr/share/fonts/100dpi:
1897    /usr/share/fonts/75dpi:
1890    /usr/share/doc/arch-wiki-markdown:
1613    /usr/include:
1575    /usr/share/doc/efl/html:
1556    /usr/share/dolphin-emu/sys/GameSettings:

私が思うのはinclude、プログラムが最初にどのディレクトリを見るかだけだと思います-同じファイルでハードリンクされているからです。上記のようなものです。私はそれについて間違っている可能性があります-そして私は修正を歓迎します...

DU DEMO

% du --version
> du (GNU coreutils) 8.22

テストディレクトリを作成します。

% mkdir ~/test ; cd ~/test
% du --inodes -S
> 1       .

一部の子ディレクトリ：

% mkdir ./realdir ./linkdir
% du --inodes -S
> 1       ./realdir
> 1       ./linkdir
> 1       .

いくつかのファイルを作成します。

% printf 'touch ./realdir/file%s\n' `seq 1 100` | . /dev/stdin
% du --inodes -S
> 101     ./realdir
> 1       ./linkdir
> 1       .

いくつかのハードリンク：

% printf 'n="%s" ; ln ./realdir/file$n ./linkdir/link$n\n' `seq 1 100` | 
    . /dev/stdin
% du --inodes -S
> 101     ./realdir
> 1       ./linkdir
> 1       .

ハードリンクを見てください：

% cd ./linkdir
% du --inodes -S
> 101

% cd ../realdir
% du --inodes -S
> 101

それらは単独でカウントされますが、1つ上のディレクトリに移動します...

% cd ..
% du --inodes -S
> 101     ./realdir
> 1       ./linkdir
> 1       .

次に、下から実行スクリプトを実行し、

> 100     /home/mikeserv/test/realdir
> 100     /home/mikeserv/test/linkdir
> 2       /home/mikeserv/test

そしてグレームズ：

> 101 ./realdir
> 101 ./linkdir
> 3 ./

したがって、これは、iノードをカウントする唯一の方法がiノードによることを示していると思います。また、ファイルのカウントはiノードのカウントを意味するため、iノードを二重にカウントすることはできません。ファイルを正確にカウントするために、iノードを複数回カウントすることはできません。

SO Q＆Aというタイトルのこの回答を使用しました：私のすべてのiノードはどこで使用されていますか？NASが約2年前に使い果たしたとき：

$ find . -type d -print0 \
    | while IFS= read -rd '' i; do echo $(ls -a "$i" | wc -l) "$i"; done \
    | sort -n

例

$ find . -type d -print0 \
    | while IFS= read -rd '' i; do echo $(ls -a "$i" | wc -l) "$i"; done \
    | sort -n
...
110 ./MISC/nodejs/node-v0.8.12/out/Release/obj.target/v8_base/deps/v8/src
120 ./MISC/nodejs/node-v0.8.12/doc/api
123 ./apps_archive/monitoring/nagios/nagios-check_sip-1.3/usr/lib64/nagios
208 ./MISC/nodejs/node-v0.8.12/deps/openssl/openssl/doc/crypto
328 ./MISC/nodejs/node-v0.8.12/deps/v8/src
453 ./MISC/nodejs/node-v0.8.12/test/simple

デバイスのiノードの確認

NASによっては、完全な機能を備えたdfコマンドを提供しない場合があります。したがって、これらの場合、tune2fs代わりに使用することに頼ることができます：

$ sudo tune2fs -l /dev/sda1 |grep -i inode
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Inode count:              128016
Free inodes:              127696
Inodes per group:         2032
Inode blocks per group:   254
First inode:              11
Inode size:           128
Journal inode:            8
Journal backup:           inode blocks

ファイルシステムの境界を越える

-xdevスイッチを使用して、find検索を開始するデバイスのみに検索を絞り込むように指示できます。

例

/home名前がmulderであるNASからNFS共有を介してディレクトリを自動マウントするとします。

$ df -h /home/sam 
Filesystem            Size  Used Avail Use% Mounted on
mulder:/export/raid1/home/sam
                      917G  572G  299G  66% /home/sam

マウントポイントはまだシステムのローカルと見なされていることに注意してください。

$ df -h /home/ .
Filesystem            Size  Used Avail Use% Mounted on
-                        0     0     0   -  /home
/dev/mapper/VolGroup00-LogVol00
                      222G  159G   52G  76% /

今私が開始するときfind：

$ find / -xdev  | grep '^/home'
/home

/home別のデバイスにあるため、自動マウントされたコンテンツは見つかりませんでした！

ファイルシステムの種類

のスイッチを使用してfind、-fstypeどのタイプのファイルシステムfindを調べるかを制御できます。

   -fstype type
          File is on a filesystem of type type.  The valid filesystem types 
          vary among different versions of Unix; an incomplete list of 
          filesystem  types that are accepted on some version of Unix or 
          another is: ufs, 4.2, 4.3, nfs, tmp, mfs, S51K, S52K.  You can use 
          -printf with the %F directive to see the types of your
          filesystems.

例

どんなファイルシステムがありますか？

$ find . -printf "%F\n" | sort -u
ext3

したがって、これを使用して交差を制御できます。

ext3のみ

$ find . -fstype ext3 | head -5
.
./gdcm
./gdcm/gdcm-2.0.16
./gdcm/gdcm-2.0.16/Wrapping
./gdcm/gdcm-2.0.16/Wrapping/CMakeLists.txt

NFSのみ

$ find . -fstype nfs | head -5
$ 

ext3およびext4

$ find . -fstype ext3 -o -fstype ext4 | head -5
.
./gdcm
./gdcm/gdcm-2.0.16
./gdcm/gdcm-2.0.16/Wrapping
./gdcm/gdcm-2.0.16/Wrapping/CMakeLists.txt

使用されるiノードを見つけるコマンド：

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

の詳細なiノードの使用法をリストする/には、次のコマンドを使用します。

echo "Detailed Inode usage for: $(pwd)" ; for d in `find -maxdepth 1 -type d |cut -d\/ -f2 |grep -xv . |sort`; do c=$(find $d |wc -l) ; printf "$c\t\t- $d\n" ; done ; printf "Total: \t\t$(find $(pwd) | wc -l)\n" 

最大の賛成票で確実に答えることは、LinuxおよびUNIXのiノードの概念を理解するのに役立ちますが、ディスクからiノードを削除または削除する実際の問題に対処する場合には、実際には役に立ちません。ubuntuベースのシステムでこれを行う簡単な方法は、不要なLinuxカーネルヘッダーとイメージを削除することです。

sudo apt-get autoremove

あなたのためにそれをします。私の場合、iノードの使用率は78％で、アラートが発生したためです。

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/xvda1     524288 407957 116331   78% /
none           957443      2 957441    1% /sys/fs/cgroup
udev           956205    388 955817    1% /dev
tmpfs          957443    320 957123    1% /run
none           957443      1 957442    1% /run/lock
none           957443      1 957442    1% /run/shm
none           957443      5 957438    1% /run/user

sudo apt-get autoremoveコマンドを実行した後、29％になりました

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/xvda1     524288 150472 373816   29% /
none           957443      2 957441    1% /sys/fs/cgroup
udev           956205    388 955817    1% /dev
tmpfs          957443    320 957123    1% /run
none           957443      1 957442    1% /run/lock
none           957443      1 957442    1% /run/shm
none           957443      5 957438    1% /run/user

これは私の時間を節約するための私の観察でした。人々はこれよりも良い解決策を見つけるかもしれません。

次のコマンドを使用すると、ドリルダウンがより迅速かつ簡単になります。

$ sudo du -s --inodes * | sort -rn

170202  var
157325  opt
103134  usr
53383   tmp
<snip>

次にvar、たとえば、ディレクトリを使用する大きなiノードがそこにあることを確認します。

これまでのすべての答えは、すべての問題に寄与する多くのサブディレクトリではなく、単一のディレクトリ内の多くのファイルに問題があることを前提としています。幸いなことに、解決策は、使用するフラグを少なくすることです。

# du --inodes --one-file-system /var | sort --numeric-sort
...
2265    /var/cache/salt/minion
3818    /var/lib/dpkg/info
3910    /var/lib/dpkg
4000    /var/cache/salt/master/gitfs/refs
4489    /var/lib
5709    /var/cache/salt/master/gitfs/hash
12954   /var/cache/salt/master/gitfs
225058  /var/cache/salt/master/jobs
241678  /var/cache/salt/master
243944  /var/cache/salt
244078  /var/cache
248949  /var

または、より短いオプションで：du --inodes -x | sort -n。残念ながら、すべてのバージョンにduinodesオプションがあるわけではありません。