Finden Sie heraus, wo Inodes verwendet werden


189

Daher erhielt ich von unserem Überwachungssystem auf einer unserer Boxen eine Warnung, dass die Anzahl der freien Inodes in einem Dateisystem niedrig wurde.

df -i Ausgabe zeigt dies:

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

Wie Sie sehen, werden in der Root-Partition 81% der Inodes verwendet.
Ich vermute, sie werden alle in einem einzigen Verzeichnis verwendet. Aber wie kann ich herausfinden, wo sich das befindet?

Antworten:


214

Ich habe diese Frage beim Stackoverflow gesehen, aber ich mochte keine der Antworten, und es ist wirklich eine Frage, die auf jeden Fall hier bei U & L sein sollte.

Grundsätzlich wird für jede Datei im Dateisystem ein Inode verwendet. Wenn Ihnen die Inodes ausgehen, liegen im Allgemeinen viele kleine Dateien herum. Es stellt sich also die Frage, in welchem ​​Verzeichnis sich eine große Anzahl von Dateien befindet.

In diesem Fall ist das Dateisystem, um das es uns geht, das Root-Dateisystem. Daher /können wir den folgenden Befehl verwenden:

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

Dadurch wird eine Liste aller Verzeichnisse im Dateisystem erstellt, denen die Anzahl der Dateien (und Unterverzeichnisse) in diesem Verzeichnis vorangestellt ist. Somit befindet sich das Verzeichnis mit der größten Anzahl von Dateien am unteren Rand.

In meinem Fall ergibt sich Folgendes:

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

Also /var/spool/postfix/maildropverbraucht im Grunde alle Inodes.

Beachten Sie, dass diese Antwort drei Vorbehalte enthält, die ich mir vorstellen kann. Mit Zeilenumbrüchen im Pfad wird nicht richtig umgegangen. Ich weiß, dass mein Dateisystem keine Dateien mit Zeilenumbrüchen enthält, und da dies nur für den menschlichen Verzehr verwendet wird, ist das potenzielle Problem keine Lösung wert (und man kann das \nmit \0und die Verwendung sort -zoben immer ersetzen ). Es wird auch nicht behandelt, wenn die Dateien auf eine große Anzahl von Verzeichnissen verteilt sind. Dies ist jedoch unwahrscheinlich, daher halte ich das Risiko für akzeptabel. Es werden auch mehrere Male Hardlinks zu derselben Datei gezählt (also nur ein Inode verwendet). Auch hier ist es unwahrscheinlich, dass falsch positive Ergebnisse erzielt werden


Der Hauptgrund, warum ich keine der Antworten auf die Stapelüberlaufantwort mochte, ist, dass alle Dateisystemgrenzen überschreiten. Da sich mein Problem im Root-Dateisystem befand, bedeutet dies, dass es jedes einzelne gemountete Dateisystem durchquert. Werfen -xdevauf den Fund Befehle würden nicht einmal richtig funktionieren.
Die am häufigsten gewählte Antwort lautet beispielsweise:

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

Wenn wir dies stattdessen auf ändern

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

Obwohl /mnt/fooes sich um ein Mount handelt, handelt es sich auch um ein Verzeichnis im Root-Dateisystem, so dass es auftaucht find . -mount -type dund dann an das weitergeleitet wird ls -a $i, das in das Mount eintaucht.

In findmeiner Antwort wird stattdessen das Verzeichnis jeder einzelnen Datei auf dem Mount aufgelistet. Also im Grunde mit einer Dateistruktur wie:

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

wir landen mit

/foo
/foo
/pop

Wir müssen also nur die Anzahl der doppelten Zeilen zählen.


2
@MohsenPahlevanzadeh, das ist nicht Teil meiner Antwort. Ich habe kommentiert, warum mir die Lösung nicht gefällt, da sie eine häufige Antwort auf diese Frage ist.
Patrick

7
Die Verwendung einer Bindungsbereitstellung ist eine robustere Methode, um das Durchsuchen anderer Dateisysteme zu vermeiden, da der Zugriff auf Dateien unter Bereitstellungspunkten möglich ist. Stellen Sie sich zum Beispiel vor, ich erstelle unter 300.000 Dateien /tmpund später wird das System so konfiguriert, dass es ein tmpfs anhängt /tmp. Dann können Sie die Dateien nicht findalleine finden. Unwahrscheinlich senario, aber erwähnenswert.
Graeme

2
Beide Arbeiten mussten nur sort entfernen, da sort eine Datei erstellen muss, wenn die Ausgabe groß genug ist, was nicht möglich war, da ich zu 100% Inodes verwendet habe.
Qwertzguy

1
Beachten Sie, dass -printfanscheinend eine GNU-Erweiterung zu finden ist, da die in OS X verfügbare BSD-Version diese nicht unterstützt.
Xiong Chiamiov

1
Die Annahme, dass sich alle Dateien in einem einzigen Verzeichnis befinden, ist schwierig. Viele Programme wissen, dass viele Dateien in einem einzigen Verzeichnis eine schlechte Leistung haben und daher eine oder zwei Ebenen von Verzeichnissen haben
PlasmaHH

26

Dies wird von hier aus auf Geheiß des Fragestellers neu gepostet:

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

Und wenn Sie im selben Dateisystem bleiben möchten, tun Sie Folgendes:

du --inodes -xS

Hier ist ein Beispiel für die Ausgabe:

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

JETZT MIT LS:

Einige Personen gaben an, dass sie keine aktuellen coreutils haben und die Option --inodes für sie nicht verfügbar ist. Also, hier ist 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

Wenn Sie neugierig sind, die Herz-und-Seele dieser langweilig bisschen regexes ersetzt die filenamein jedem der ls'srekursiven Suchergebnisse mit dem Verzeichnisnamen , in dem es gefunden wurde. Von da an müssen Sie nur nochmalige Inode-Nummern auspressen, dann nochmalige Verzeichnisnamen zählen und entsprechend sortieren.

Die -UOption ist besonders hilfreich bei der Sortierung, da sie die Verzeichnisliste nicht speziell sortiert, sondern in der ursprünglichen Reihenfolge - oder mit anderen Worten nach inodeNummer - anzeigt.

Und das ist natürlich -1unglaublich hilfreich, da es ein einziges Ergebnis pro Zeile sicherstellt, unabhängig davon, ob möglicherweise neue Zeilen in den Dateinamen enthalten sind oder andere auffallend unglückliche Probleme, die auftreten können, wenn Sie versuchen, eine Liste zu analysieren.

Und natürlich -Afür alle und -ifür inode und -Rfür rekursiv und das ist das lange und kurze.

Die zugrunde liegende Methode besteht darin, dass ich jeden Dateinamen von ls durch den darin enthaltenen Verzeichnisnamen in sed ersetze. Daran anknüpfen ... Nun, ich bin selbst ein bisschen verschwommen. Ich bin mir ziemlich sicher, dass die Dateien genau gezählt werden, wie Sie hier sehen können:

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

Dies liefert mir ziemlich identische Ergebnisse wie der duBefehl:

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:

Ich denke, die includeSache hängt nur davon ab, auf welches Verzeichnis das Programm zuerst schaut - weil sie die gleichen Dateien und fest verbunden sind. Irgendwie gefällt mir das Ding oben. Daran könnte ich mich jedoch irren - und ich begrüße die Korrektur ...

DU DEMO

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

Erstellen Sie ein Testverzeichnis:

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

Einige Kinderverzeichnisse:

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

Machen Sie einige Dateien:

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

Einige Hardlinks:

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

Schauen Sie sich die Hardlinks an:

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

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

Sie werden alleine gezählt, gehen aber ein Verzeichnis hoch ...

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

Dann habe ich mein Skript von unten ausgeführt und:

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

Und Graemes:

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

Ich denke, das zeigt, dass der einzige Weg, Inodes zu zählen, der Inode ist. Und weil das Zählen von Dateien das Zählen von Inodes bedeutet, können Sie Inodes nicht doppelt zählen - um Dateien genau zu zählen, können Inodes nicht mehr als einmal gezählt werden.


2
welche version hinzugefügt --inodes? welche "varianten" / "aromen" / "posix-wannabes" / "implementierungen" / was haben sie?
n611x007

Ubuntu 14.04.5: du: nicht erkannte Option '--inodes'
Putnik

du (GNU coreutils) 8.23 ​​von 2014 hat es (es ist in meinem veralteten Debian Jessie). Debian> Ubuntu Entschuldigung für dieses Wortspiel: P Ubuntu hat so alte Pakete ...
Daniel W.

6

Ich habe diese Antwort von SO Q & A mit dem Titel: Wo werden alle meine Inodes verwendet? als unser NAS vor ca. 2 Jahren ausgegangen ist:

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

Beispiel

$ 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

Überprüfen der Inodes des Geräts

Abhängig von Ihrem NAS wird möglicherweise kein voll funktionsfähiger dfBefehl angeboten. In diesen Fällen können Sie tune2fsstattdessen auf Folgendes zurückgreifen :

$ 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

Dateisystemgrenzen überschreiten

Mit dem -xdevSchalter können findSie die Suche auf das Gerät beschränken, auf dem Sie die Suche starten.

Beispiel

Angenommen, ich habe mein /homeVerzeichnis automatisch über NFS-Freigaben von meinem NAS bereitgestellt, dessen Name mulder ist.

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

Beachten Sie, dass der Einhängepunkt weiterhin als lokal für das System betrachtet wird.

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

Wenn ich jetzt initiiere find:

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

Es wurde /homeaber keiner der automatisch gemounteten Inhalte gefunden, da diese sich auf einem anderen Gerät befinden!

Dateisystemtypen

Sie können den Schalter auf verwenden find, um -fstypezu steuern, in welche Art von Dateisystemen gesucht findwird.

   -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.

Beispiel

Welches Dateisystem habe ich?

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

So können Sie die Überfahrt steuern:

nur 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

nur 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

Was wäre Ihre Lösung, um zu verhindern, dass Dateisystemgrenzen überschritten werden? Wenn /beispielsweise alles voll ist und Sie Netzwerk-Dateisysteme bereitgestellt haben, möchten Sie nicht in die Netzwerk-Dateisysteme eintauchen.
Patrick

@Patrick - siehe Updates, du kannst es mit -fstypeto steuern find.
SLM

1
@ Gilles - einfache Antwort ... hat in
Finds

@Gilles - Die Manpage scheint nicht anzuzeigen, dass -xtypeDateisysteme ausgeschlossen sind, sondern den Dateityp. Ich find . \( -fstype nfs -prune \)
finde

@ Gilles - Ich habe Patrick's Q in den Kommentaren darüber angesprochen, wie ich verhindern kann, dass findDateisystemgrenzen überschritten werden. In seiner Ex. Er erwähnt "Wenn / voll ist und Sie Netzwerk-Dateisysteme gemountet haben, möchten Sie nicht in die Netzwerk-Dateisysteme eintauchen".
SLM

4

Befehl zum Finden der verwendeten Inode:

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

3

/Verwenden Sie den folgenden Befehl, um die detaillierte Inode-Verwendung für aufzulisten :

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" 

Willkommen hier! Ich schlage vor, das nächste Mal besser zu formatieren, bitte.
Peter

1
Es ist ein Oneliner, daran sehe ich nichts auszusetzen.
So

2

Antworten Sie auf jeden Fall mit maximalen Upvotes, um das Konzept der Inodes unter Linux und Unix zu verstehen. Es hilft jedoch nicht wirklich, wenn es um das eigentliche Problem des Löschens oder Entfernens der Inodes von der Festplatte geht. Eine einfachere Möglichkeit, dies auf Ubuntu-basierten Systemen zu tun, besteht darin, unerwünschte Linux-Kernel-Header und -Images zu entfernen.

sudo apt-get autoremove

Würde das für dich tun. In meinem Fall lag die Inodes-Auslastung bei 78%, weshalb ich benachrichtigt wurde.

$ 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

Nach dem Ausführen des sudo apt-get autoremoveBefehls war es auf 29% gesunken

$ 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

Dies war nur meine Beobachtung, die mir Zeit sparte. Die Leute finden vielleicht eine bessere Lösung als diese.


2

Ich finde es schneller und einfacher, mit dem folgenden Befehl einen Drilldown durchzuführen:

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

170202  var
157325  opt
103134  usr
53383   tmp
<snip>

Sie können dann varzum Beispiel nachsehen, wo sich die großen Inodes mit Verzeichnissen befinden.


0

Bisher wird bei jeder Antwort davon ausgegangen, dass sich das Problem in vielen Dateien in einem einzigen Verzeichnis befindet und nicht in vielen Unterverzeichnissen, die alle zum Problem beitragen. Glücklicherweise besteht die Lösung darin, einfach weniger Flags zu verwenden.

# 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

Oder mit kürzeren Optionen: du --inodes -x | sort -n. Leider haben nicht alle Versionen dudie Option inodes.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.