VMware ESXi and vSphere Cluster Management

Inodes in Linux verstehen

Was sind Inodes in Linux? Erklärt werden Metadaten, Verzeichniseinträge, Hard Links, Symlinks, Inode-Erschöpfung sowie die Analyse mit ls, stat und df -i.

Was ist eine Inode?

Eine Inode ist ein Metadateneintrag eines Linux-Dateisystems für ein Dateisystemobjekt. Ein solches Objekt kann beispielsweise eine reguläre Datei, ein Verzeichnis, ein symbolischer Link, eine Gerätedatei, ein Socket oder eine FIFO sein.

Die Inode beschreibt das Objekt, speichert aber normalerweise nicht dessen Dateinamen. Sie enthält unter anderem Dateityp, Berechtigungen, Eigentümer, Zeitstempel, Größe und die Zuordnung zu den Datenblöcken. Die Inode-Nummer ist eine numerische Kennung dieser Inode innerhalb eines bestimmten Dateisystems.

Dateiname, Verzeichniseintrag, Inode und Datenblöcke

Ein Pfad wie /var/log/app.log setzt sich aus mehreren Informationen zusammen. Ein Verzeichnis enthält Zuordnungen von Namen zu Inode-Nummern. Ein solcher Datensatz heißt Verzeichniseintrag. Der Name app.log verweist dort beispielsweise auf die Inode-Nummer 48192.

Die Inode mit der Nummer 48192 enthält die Metadaten des Objekts. Zeiger oder andere dateisystemspezifische Zuordnungen führen zu den Datenblöcken, in denen der Dateiinhalt gespeichert ist. Deshalb ist der Dateiname nicht der eigentliche Bestandteil der Inode: Mehrere Namen können auf dieselbe Inode zeigen.

Welche Information liegt wo?

Information — Verzeichniseintrag — Inode — Datenblöcke

Dateiname — gespeichert — nicht als eigentlicher Bestandteil — nein

Inode-Nummer — Ziel der Zuordnung — eigene Kennung — nein

Eigentümer und Rechte — nein — gespeichert — nein

Zeitstempel — nein — gespeichert — nein

Dateigröße — nein — gespeichert — nein

Dateiinhalt — nein — Verweis auf Speicherbereiche — gespeichert

Was passiert beim Anlegen einer Datei?

  1. Das Dateisystem reserviert eine freie Inode und trägt Dateityp sowie weitere Metadaten ein.
  2. Im übergeordneten Verzeichnis wird ein Verzeichniseintrag angelegt. Er verbindet den neuen Namen mit der Inode-Nummer.
  3. Für den Inhalt werden bei Bedarf Datenblöcke reserviert. Bei einer leeren Datei existieren möglicherweise noch keine Datenblöcke für Nutzdaten.

Was passiert beim Löschen?

Beim Löschen eines Namens wird zunächst der Verzeichniseintrag entfernt. Der Link-Zähler der Inode sinkt. Erst wenn kein Hard Link mehr auf die Inode zeigt und keine offenen Dateideskriptoren mehr auf die Datei verweisen, kann das Dateisystem Inode und Datenblöcke freigeben.

Ein Dateideskriptor ist eine prozessinterne Referenz auf eine geöffnete Datei. Ein Prozess kann daher noch mit einer Datei arbeiten, obwohl ihr Name bereits gelöscht wurde. Der belegte Speicher wird häufig erst freigegeben, wenn der Prozess die Datei schließt oder beendet wird.

Welche Metadaten enthält eine Inode?

  • Dateityp: etwa reguläre Datei, Verzeichnis, symbolischer Link, Gerätedatei, Socket oder FIFO.
  • Dateimodus: Dateityp und Zugriffsrechte wie Lesen, Schreiben und Ausführen für Eigentümer, Gruppe und andere.
  • Eigentümer: Benutzer-ID und Gruppen-ID.
  • Dateigröße: die logische Größe des Objekts in Bytes.
  • Zeitstempel: je nach Dateisystem unter anderem die letzte Inhaltsänderung, die letzte Metadatenänderung und der letzte Zugriff.
  • Link-Zähler: die Anzahl der Verzeichniseinträge, die auf diese Inode zeigen.
  • Datenzuordnung: Zeiger oder Strukturen, die den Dateiinhalt Datenblöcken zuordnen.
  • Weitere Attribute: Dateisystemspezifische Flags, Prüfinformationen, Projektzugehörigkeit oder andere implementierungsabhängige Werte.

Die genaue Darstellung und Bedeutung einzelner Felder hängt vom Dateisystem und von den verwendeten Werkzeugen ab. Die Zeitstempel werden häufig als atime für den letzten Zugriff, mtime für die letzte Inhaltsänderung und ctime für die letzte Änderung von Metadaten bezeichnet. ctime ist nicht der Erstellungszeitpunkt.

Inodes mit Shell-Werkzeugen untersuchen

Inode-Nummer mit ls anzeigen

Die Option -i zeigt die Inode-Nummer. Mit -l wird zusätzlich die lange Dateiliste ausgegeben.

$ printf 'Hallo
' > beispiel.txt
$ ls -il beispiel.txt
48192 -rw-r--r-- 1 user user 6 Aug 18 10:15 beispiel.txt

Die erste Zahl, hier 48192, ist die Inode-Nummer. Danach folgen unter anderem Dateimodus, Link-Zähler, Eigentümer, Gruppe, Größe, Zeitstempel und Name.

$ ls -li VERZEICHNIS

Bei der Analyse muss die Inode-Nummer immer zusammen mit dem Dateisystem betrachtet werden. Dieselbe Zahl kann auf einem anderen Dateisystem zu einer völlig anderen Inode gehören.

Ausführliche Informationen mit stat

$ stat beispiel.txt
  File: beispiel.txt
  Size: 6          Blocks: 8          IO Block: 4096   regular file
Device: ...        Inode: 48192       Links: 1
Access: (0644/-rw-r--r--)  Uid: (...)   Gid: (...)
Access: 2026-08-18 10:15:00
Modify: 2026-08-18 10:15:00
Change: 2026-08-18 10:15:00

stat zeigt unter anderem Inode-Nummer, Link-Zähler, Dateityp, Rechte, Eigentümer, Größe und Zeitstempel. Die Ausgabe kann je nach Betriebssystem und Dateisystem leicht abweichen.

Hard Links

Ein Hard Link ist ein zusätzlicher Verzeichniseintrag für dieselbe Inode. Zwei Namen sind dann keine zwei unabhängigen Dateien, sondern zwei Namen für dasselbe Dateisystemobjekt.

$ printf 'erste Version
' > original.txt
$ ln original.txt hardlink.txt
$ ls -li original.txt hardlink.txt
48201 -rw-r--r-- 2 user user 14 Aug 18 10:20 hardlink.txt
48201 -rw-r--r-- 2 user user 14 Aug 18 10:20 original.txt

Beide Namen zeigen auf die Inode 48201. Der Link-Zähler beträgt 2. Änderungen am Inhalt, an den Rechten oder an anderen Inode-Metadaten betreffen daher dasselbe Objekt.

$ printf 'geändert
' > original.txt
$ cat hardlink.txt
geändert
$ rm original.txt
$ cat hardlink.txt
geändert

Das Löschen eines Namens löscht die Inode nicht sofort, solange der andere Hard Link noch vorhanden ist.

  • Hard Links können üblicherweise nicht über Dateisystemgrenzen hinweg erstellt werden.
  • Für Verzeichnisse sind Hard Links normalerweise nicht erlaubt, weil dadurch problematische Zyklen in der Verzeichnisstruktur entstehen könnten.
  • Hard Links verweisen auf eine Inode, nicht auf einen Namen. Wird ein Name verschoben, bleibt der andere Verzeichniseintrag gültig.

Symbolische Links

Ein symbolischer Link oder Symlink ist ein eigenes Dateisystemobjekt. Seine Inode speichert einen Zielpfad, beispielsweise original.txt. Beim Zugriff wertet Linux diesen Pfad aus und versucht, das Ziel zu öffnen.

$ ln -s original.txt symlink.txt
$ ls -li original.txt hardlink.txt symlink.txt
48201 -rw-r--r-- 2 user user 14 Aug 18 10:20 hardlink.txt
48201 -rw-r--r-- 2 user user 14 Aug 18 10:20 original.txt
48205 lrwxrwxrwx 1 user user 12 Aug 18 10:21 symlink.txt -> original.txt

Der Symlink hat die Inode-Nummer 48205, während Ziel und Hard Link die Inode 48201 verwenden. Das Zeichen l im Dateimodus kennzeichnet den symbolischen Link.

Hard Link und symbolischer Link im Vergleich

Eigenschaft — Hard Link — symbolischer Link

Eigene Inode — nein, nutzt die Inode des Ziels — ja, der Link ist ein eigenes Objekt

Bezug zum Ziel — direkte gemeinsame Inode — gespeicherter Pfad

Gleiche Inode-Nummer wie Ziel — ja — nein

Nach Löschen des Zielnamens — funktioniert weiter, wenn ein Hard Link verbleibt — kann ungültig werden

Dateisystemgrenzen — üblicherweise nicht überschreitbar — Ziel kann auf anderem Dateisystem liegen

Typische Einsatzfälle — zusätzliche Namen für dasselbe Objekt — flexible Pfade, Verweise auf Verzeichnisse oder Ziele in anderen Dateisystemen

Ein Symlink kann auch dann existieren, wenn sein Ziel nicht mehr vorhanden ist. Das nennt man einen ungültigen oder dangling Symlink. Beim Verschieben eines relativen Ziels kann sich außerdem die Bedeutung des Links ändern, weil der gespeicherte Pfad relativ zum Speicherort des Links interpretiert wird.

Inodes und Speicherplatz

Linux-Dateisysteme verwalten mindestens zwei unterschiedliche knappe Ressourcen:

  • Blockspeicher: Kapazität für Dateiinhalt und bestimmte Verwaltungsdaten.
  • Inodes: Datensätze für Dateisystemobjekte.

Eine Datei benötigt typischerweise mindestens eine Inode, auch wenn sie leer ist. Deshalb können sehr viele kleine Dateien die Inodes erschöpfen, bevor der Blocks­peicher vollständig belegt ist. In diesem Zustand kann das Erstellen einer weiteren Datei fehlschlagen, obwohl df -h noch freien Speicher anzeigt.

Blockspeicher-Mangel und Inode-Mangel unterscheiden

Merkmal — Blocks­peicher erschöpft — Inodes erschöpft

df-Auswertung — belegte Kapazität nahe 100 Prozent — kann noch freie Kapazität zeigen

df -i-Auswertung — Inodes können noch frei sein — Inode-Nutzung nahe 100 Prozent

Typische Ursache — große Dateien oder viele Daten — sehr viele kleine Dateien

Mögliche Fehlermeldung — „No space left on device“ — ebenfalls häufig „No space left on device“

Gegenmaßnahme — große oder unnötige Daten kontrolliert entfernen oder Speicher erweitern — Dateianzahl reduzieren, Aufbewahrung verbessern oder passenderes Layout wählen

Inode-Erschöpfung kann Logs, temporäre Dateien, Cache-Dateien, Uploads, Build-Artefakte und Paketinstallationen beeinträchtigen. Anwendungen können dann auch bei scheinbar ausreichender Datenkapazität keine neuen Dateien, Sockets oder temporären Arbeitsdateien anlegen.

Dateisystemabhängiges Verhalten

Die Verwaltung von Inodes ist eine Eigenschaft des konkreten Dateisystems. Es gibt daher keine allgemeingültige feste Inode-Anzahl für alle Linux-Dateisysteme.

ext3 und ext4

Bei der ext-Familie wird die Inode-Kapazität wesentlich beim Anlegen beziehungsweise Formatieren des Dateisystems geplant. Parameter wie die erwartete Anzahl kleiner Dateien beeinflussen das Layout. Eine nachträgliche Änderung der Inode-Struktur ist nicht so flexibel wie eine reine Erweiterung des Blocks­peichers.

XFS

XFS verwaltet Inodes anders und deutlich dynamischer als die ext-Familie. Das bedeutet nicht, dass XFS unbegrenzt viele Dateien aufnehmen kann: Auch dort gelten Speicher-, Verwaltungs- und Dateisystemgrenzen. Für die Diagnose zählt deshalb immer die konkrete Ausgabe von df -i und der verwendete Dateisystemtyp.

Inode-Verbrauch prüfen

Mountpoint und Dateisystem feststellen

$ findmnt -T /var/log
TARGET   SOURCE     FSTYPE OPTIONS
/var     /dev/...   ext4   rw,...

findmnt -T PFAD zeigt, welchem Mountpoint und welchem Dateisystem ein Pfad zugeordnet ist. Das verhindert, dass Werte eines übergeordneten oder anders eingehängten Dateisystems falsch interpretiert werden.

Blockspeicher und Inodes vergleichen

$ df -h /var
Filesystem      Size  Used Avail Use% Mounted on
/dev/...        100G   62G   38G  63% /var

$ df -i /var
Filesystem       Inodes   IUsed   IFree IUse% Mounted on
/dev/...        6500000 6485000   15000  100% /var

Im Beispiel sind erst 63 Prozent des Blocks­peichers belegt, aber praktisch alle Inodes sind verbraucht. Das erklärt, warum neue Dateien scheitern können.

Viele kleine Dateien lokalisieren

Typische Kandidaten sind Cache-, Build-, Upload- und temporäre Verzeichnisse. Eine einfache Zählung regulärer Dateien unterhalb eines Pfads lautet:

$ find /var/tmp -xdev -type f | wc -l

Die Option -xdev verhindert, dass find in andere eingehängte Dateisysteme hineinläuft. Dadurch bleibt die Zählung dem untersuchten Dateisystem zugeordnet.

Vor einer Bereinigung sollten Verzeichnisse fachlich bewertet und Aufbewahrungsregeln geprüft werden. Nicht jede alte Datei ist entbehrlich. Besonders bei Logs, Uploads und Build-Artefakten müssen Anwendung, Compliance und Wiederherstellbarkeit berücksichtigt werden.

Fehlerdiagnose in der Praxis

„Kein Speicherplatz“, obwohl noch Kapazität frei ist

  1. Den betroffenen Pfad mit findmnt -T PFAD dem richtigen Mountpoint und Dateisystem zuordnen.
  2. Mit df -h MOUNTPOINT den Blocks­peicher prüfen.
  3. Mit df -i MOUNTPOINT die Inode-Auslastung prüfen.
  4. Verzeichnisse mit sehr vielen kleinen Dateien zählen und die Ursache des Wachstums feststellen.
  5. Nur Dateien bereinigen, die nach einer definierten Aufbewahrungsregel entbehrlich sind.
  6. Die Werte mit df -h und df -i vor und nach der Maßnahme vergleichen.

Wenn das Problem regelmäßig wiederkehrt, helfen eine automatische Bereinigung, passendere Aufbewahrungsregeln oder die Verlagerung des Workloads auf ein geeignetes Volume beziehungsweise Dateisystem.

Gelöschter Name, aber Speicher bleibt belegt

Zuerst sollten weitere Hard Links geprüft werden. Gleiche Inode-Nummern bei verschiedenen Namen und ein Link-Zähler größer als eins weisen darauf hin. Danach ist zu prüfen, ob ein Prozess die Datei noch geöffnet hält. Ein kontrollierter Neustart oder das Beenden des zuständigen Prozesses kann den Speicher freigeben, sofern dies betrieblich zulässig ist.

Zwei Namen ändern sich gemeinsam

Mit ls -il lässt sich feststellen, ob beide Namen dieselbe Inode-Nummer besitzen. stat zeigt zusätzlich den Link-Zähler. Wenn unabhängige Inhalte benötigt werden, muss eine echte Kopie erstellt werden; ein Hard Link reicht dafür nicht aus.

Symlink funktioniert nach einer Änderung nicht mehr

Das gespeicherte Ziel eines Symlinks muss kontrolliert werden. Ein verschobenes oder gelöschtes Ziel kann den Link ungültig machen. Je nach gewünschtem Verhalten wird der Symlink auf den gültigen Pfad neu erstellt oder das Ziel wiederhergestellt. Bei relativen Pfaden ist zusätzlich der Speicherort des Symlinks zu berücksichtigen.

Prüfungsrelevante Zusammenfassung

  • Eine Inode ist ein Metadatensatz für ein Dateisystemobjekt.
  • Ein Verzeichnis ordnet Namen Inode-Nummern zu.
  • Der Dateiname ist nicht die zentrale Identität des Objekts; die Inode-Nummer identifiziert die Inode innerhalb eines Dateisystems.
  • Hard Links sind mehrere Namen für dieselbe Inode.
  • Ein symbolischer Link ist ein eigenes Objekt mit eigenem Inode-Datensatz und gespeichertem Zielpfad.
  • Der Link-Zähler sinkt beim Entfernen eines Namens. Freigabe erfolgt erst ohne verbliebene Hard Links und ohne offene Dateideskriptoren.
  • df -h untersucht Blocks­peicher, df -i untersucht Inodes.
  • Viele kleine Dateien können Inodes erschöpfen, obwohl noch Datenkapazität frei ist.
  • Das Verhalten hängt vom Dateisystem ab; ext3/ext4 und XFS verwalten Inodes unterschiedlich.