Was ist ein Inode?

In einem Dateisystem nach Unix-Art ist ein Inode (Indexknoten) eine Datenstruktur, die ein Dateisystemobjekt beschreibt, darunter eine Datei oder ein Verzeichnis. Jeder Inode verwaltet die Dateneigenschaften und die Adressen der Festplattenblöcke des Objekts. Metadaten (Zeitpunkte der letzten Änderung, Modifikation und des letzten Zugriffs) sowie Informationen zu Eigentümer und Berechtigungen finden sich in den Attributen des Dateisystemobjekts.

Ein Verzeichnis ist eine Sammlung von Inodes mit Namen. Es, sein übergeordnetes Verzeichnis und seine untergeordneten Verzeichnisse sind alle in der Liste vertreten.

Es war einfach ein Begriff, den die Leute zu verwenden begannen. „Index“ ist meine beste Vermutung aufgrund der relativ ungewöhnlichen Dateisystemstruktur, bei der Dateizugriffsdaten als flaches Array auf dem Laufwerk gespeichert wurden, während alle hierarchischen Verzeichnisinformationen davon getrennt vorlagen. Somit ist die i-Nummer ein Index in diesem Array, und der i-Knoten ist das ausgewählte Element des Arrays. (Im Handbuch der ersten Auflage wurde die „i-“Notation verwendet; der Bindestrich wurde später weggelassen.)

Ein Verzeichniseintrag enthält lediglich den Namen der zugehörigen Datei und einen Verweis auf die eigentliche Datei. Dieser Zeiger ist eine Ganzzahl, die als i-Nummer (Indexnummer) der Datei bezeichnet wird. Beim Zugriff auf eine Datei wird ihre i-Nummer als Index in einer Systemdatenbank (der i-Liste) verwendet, die in einem reservierten Bereich des Geräts gespeichert ist, auf dem sich das Verzeichnis befindet. Die Informationen der Datei sind in dem gefundenen Eintrag (dem i-Knoten der Datei) enthalten.

Weitere nützliche Details

Ein Dateisystem basiert auf Datenstrukturen, die sich auf Dateien beziehen, und nicht auf den Inhalten dieser Dateien. Ersteres wird als Metadaten bezeichnet – Daten, die Daten charakterisieren. Jeder Datei wird ein Inode zugewiesen, der durch eine Ganzzahl identifiziert wird, die als i-Nummer oder Inode-Nummer bekannt ist.

Inodes dienen dazu, Daten über Dateien und Verzeichnisse (Ordner) zu speichern, darunter Zugriffsrechte (Lese-, Schreib- und Ausführungsrechte), Dateibesitzer und Dateityp. In vielen früheren Dateisystemimplementierungen wird die maximale Anzahl von Inodes bei der Erstellung des Dateisystems festgelegt, wodurch die höchste Anzahl an Dateien, die das Dateisystem aufnehmen kann, begrenzt wird. Eine gängige Zuweisungsstrategie sieht einen Inode pro 2 KB in einem Dateisystem vor.

Die Inode-Nummer verweist auf eine Datenbank mit Inodes an einem bekannten Ort auf der Hardware. Der Dateisystemtreiber des Kernels kann mithilfe der Inode-Nummer auf den Inhalt des Inodes, wie beispielsweise den Speicherort der Datei, zugreifen und so Zugriff auf die Datei gewähren. Mit dem Befehl `ls -i` lässt sich die Inode-Nummer einer Datei ermitteln. Der Befehl `ls -i` zeigt die Inode-Nummer in der ersten Spalte der Ausgabe an.

Mehrere Dateisysteme im Unix-Stil, wie ReiserFS, btrfs, ZFS, APFS und OpenZFS, verfügen nicht über eine Inode-Datenbank mit fester Größe, müssen jedoch gleiche Daten enthalten, um gleichwertige Funktionen zu bieten. Die Daten werden manchmal als „stat-Daten“ bezeichnet, in Anlehnung an den Systemaufruf „stat“, der die Daten an Anwendungen liefert. B-Bäume und die davon abgeleiteten B+-Bäume sind häufige Ersatzlösungen für die Tabelle mit fester Größe.

Auswirkungen von Dateinamen und Verzeichnissen:

• In Inodes werden nur Dateimetadaten gespeichert, keine Hardlink-Namen.
• Unix-Verzeichnisse sind Sammlungen von Assoziationsstrukturen, die in der Regel einen Dateinamen und eine Inode-Nummer enthalten.
• Der Dateisystemtreiber muss ein Verzeichnis nach einem bestimmten Dateinamen durchsuchen und diesen dann in die entsprechende Inode-Nummer umwandeln.

Die In-Memory-Darstellung dieser Daten im Betriebssystemkern wird unter Linux als struct inode bezeichnet. Von BSD abgeleitete Systeme verwenden vnode (das „v“ bezieht sich auf die virtuelle Dateisystemebene des Kernels).

POSIX-Inode-Beschreibung

Der POSIX-Standard schreibt ein Dateisystemverhalten vor, das stark von früheren UNIX-Dateisystemen inspiriert ist. Der Begriff „Dateiseriennummer“ bezieht sich auf einen Inode, der als dateisystemspezifische eindeutige Kennung für ein Dokument definiert ist. Diese Dateiseriennummer identifiziert zusammen mit der ID des Geräts, auf dem sie sich befindet, eine bestimmte Datei im gesamten System.

Eine Datei auf einem POSIX-System enthält mehrere Attribute, auf die über den Systemaufruf stat zugegriffen werden kann:

• Die ID des Geräts (identifiziert die Hardware, auf der sich die Datei befindet; das heißt, den eindeutigen Geltungsbereich der Seriennummer).
• Seriennummern der Datei.
• Der Dateimodus gibt den Dateityp an sowie die Art und Weise, wie der Eigentümer, die Gruppe und andere die Datei sehen können.
• Eine Verknüpfungsanzahl gibt die Anzahl der Hardlinks an, die auf den Inode verweisen.
• Die Benutzer-ID des Dateieigentümers.
• Die Gruppen-ID der Datei.
• Wenn es sich bei der Datei um eine Gerätedatei handelt, verfügt sie über eine Geräte-ID.
• Die Größe der Datei wird in Byte angegeben.
• Zeitstempel geben an, wann der Inode zuletzt geändert wurde (Inode-Änderungszeit, ctime), wann der Dateiinhalt zuletzt bearbeitet wurde (Änderungszeit, mtime) und wann zuletzt auf den Inode zugegriffen wurde (Zugriffszeit, atime).
• Die Größe des ausgewählten E/A-Blocks.
• Die Gesamtzahl der dieser Datei zugewiesenen Blöcke.

Auswirkungen

Inode-basierte Dateisysteme weisen die folgenden administrativen Eigenschaften auf.

• Dateien können mehr als einen Namen haben. Wenn zwei oder mehr Namen über Hardlinks auf denselben Inode verweisen, sind die Namen gleichwertig; der zuerst gebildete Name hat keine besondere Bedeutung. Dies steht im Gegensatz zu symbolischen Verknüpfungen, die durch den ursprünglichen Namen und nicht durch den Inode (Nummer) bestimmt werden.
• Ein Inode kann Verknüpfungen enthalten oder auch nicht. Eine Datei ohne Verknüpfungen wird von der Festplatte gelöscht, und ihre Ressourcen werden zur Neuzuweisung freigegeben, doch muss die Löschung so lange warten, bis alle Programme, die sie geöffnet haben, ihren Zugriff darauf abgeschlossen haben. Dazu gehören auch ausführbare Dateien, die von den Programmen, die sie ausführen, offen gehalten werden.
• Normalerweise ist es nicht möglich, von einer geöffneten Datei, die zum Öffnen verwendet wurde, auf den Dateinamen zurückzuschließen. Der Dateiname wird vom Betriebssystem sofort in eine Inode-Nummer umgewandelt, bevor die Datei gelöscht wird. Das heißt, die Bibliotheksfunktionen getwd() und getcwd() suchen im übergeordneten Verzeichnis nach einer Datei mit einer Inode, die dem Arbeitsverzeichnis ähnelt, und suchen dann im übergeordneten Verzeichnis dieses Verzeichnisses, immer wieder, bis sie das Stammverzeichnis erreichen. Um dies zu ermöglichen, speichern Linux- und SVR4-Computer zusätzliche Daten.
• Damals war es möglich, Hardlinks zwischen verschiedenen Verzeichnissen zu erstellen. Im Gegensatz zu einem gerichteten azyklischen Graphen wurden Verzeichnisse dadurch in einen beliebigen gerichteten Graphen umgewandelt. Es war sogar denkbar, dass ein Verzeichnis das übergeordnete eines anderen war. Moderne Systeme verbieten diese verwirrende Situation in der Regel, mit der Ausnahme, dass das übergeordnete Verzeichnis des Stammverzeichnisses weiterhin als Stammverzeichnis klassifiziert wird. Die bemerkenswerteste Ausnahme von dieser Regel ist Mac OS X (Versionen 10.5 und höher), das es dem Superuser erlaubt, Hardlinks zu Verzeichnissen zu erstellen.
• Wenn eine Datei in ein anderes Verzeichnis auf demselben Gerät verschoben wurde oder wenn das Laufwerk defragmentiert wird, bleibt die Inode-Nummer unverändert, was ihre Verlagerung und die Möglichkeit ihrer Umbenennung ermöglicht, selbst wenn sie ohne Unterbrechung beschrieben und gelesen wird. Dies bedeutet auch, dass ein vollständig konformes Inode-Verhalten bei vielen Nicht-Unix-Dateisystemen, einschließlich FAT und dessen Nachfolgern, schwer zu implementieren ist, da ihnen ein Mechanismus fehlt, um diese Invarianz aufrechtzuerhalten, wenn sowohl der Verzeichniseintrag einer Datei als auch ihre Daten verschoben werden.
• Bei Inode-Dateisystemen ist das Hinzufügen neuer Bibliotheken ein Kinderspiel. Ein laufendes Programm kann auf ein Bibliotheksdokument zugreifen, während ein anderes Programm es gleichzeitig ersetzt, wobei ein neuer Inode und eine völlig neue Zuordnung für die neue Datei erstellt werden, um sicherzustellen, dass zukünftige Zugriffsversuche auf die Bibliothek die aktuellste Version erhalten. Diese Funktion macht einen Neustart des Computers überflüssig, um aktuell zugeordnete Bibliotheken zu ersetzen.
• Die Inodes eines Geräts können erschöpft sein. Wenn dies geschieht, können keine neuen Dokumente erstellt werden, selbst wenn im Speicher des Geräts noch freier Platz vorhanden ist. Dies ist besonders typisch in Anwendungsfällen wie Mail-Servern, die zahlreiche kleine Dateien enthalten. Extents oder dynamische Inode-Zuweisung, die das Dateisystem „erweitern“ oder die Anzahl der Inodes erhöhen können, ermöglichen es Dateisystemen (wie XFS oder JFS), dieses Problem zu umgehen.

Inlining

Es mag sinnvoll erscheinen, kleine Dateien im Inode selbst zu speichern, um Speicherplatz (kein Datenblock erforderlich) und Suchzeit (kein weiterer Zugriff auf das Laufwerk nötig) zu sparen. Dies wird im Dateisystem als Inlining bezeichnet. Bei der Verwendung aktueller Dateisysteme besteht die Erwartung einer absoluten Trennung zwischen Inode und Dateidaten möglicherweise nicht mehr.

Wenn die Informationen einer Datei in den für Datenzeiger reservierten Bereich passen, ist die Nutzung dieses Speicherplatzes vorteilhaft. Ext2 und seine Nachfolger speichern beispielsweise die Daten von Symlinks (in der Regel Dateinamen) auf diese Weise, wenn die Daten weniger als 60 Byte groß sind („schnelle symbolische Links“).

Ext4 verfügt über eine Dateisystemoption namens „inline data“, die es ext4 ermöglicht, Inlining durchzuführen, wenn sie bei der Erstellung des Dateisystems aktiviert wird. Da die Größe eines Inodes begrenzt ist, funktioniert dies nur bei kleinen Dateien. In Nicht-Unix-Systemen

• Die Master File Table (MFT) in NTFS speichert Dateien in einem B-Baum. Jeder Eintrag enthält eine „fileID“, die einer Inode-Nummer entspricht und diesen Eintrag eindeutig identifiziert. Der Eintrag umfasst drei Zeitstempel, eine Geräte-ID, Eigenschaften, eine Referenzanzahl und Dateigrößen, wobei die Darstellung der Berechtigungen nicht der von POSIX entspricht. Der Aufbau auf der Festplatte ist komplexer. Frühere FAT-Dateisysteme verfügten nicht über eine solche Tabelle und konnten keine Hardlinks erstellen.
• Darüber hinaus verfolgt NTFS das Konzept, kleine Dokumente in den MFT-Eintrag einzubetten.
• Ein ähnliches MFT existiert im abgeleiteten ReFS. ReFS verfügt über eine 128-Bit-Datei-ID; diese Erweiterung wurde auch auf NTFS zurückportiert, das zu dieser Zeit eine 64-Bit-Datei-ID hatte.
• Die gleiche stat-ähnliche GetFileInformationByHandle-API kann auf Cluster Shared Volumes und SMB 3.0 verwendet werden, was darauf hindeutet, dass diese Systeme ein gemeinsames Dateikennungs-Konzept nutzen.