Ich lese gerade das Buch „Advance UNIX Programming“ von W. Richard Stevens und habe dort gelesen, dass alle Dateien unter UNIX eine Nummer haben und dass die Dateinamen nur aus Benutzerfreundlichkeit erstellt werden. Wenn ein Verzeichnis aufgerufen wird, sucht das System anhand der Nummer nach dem eingegebenen Namen.
Ich habe mir gedacht, wie suchen die nach der Nummer? Sind die Dateien nach Namen sortiert abgelegt, so dass man sie per binärer Suche finden kann? Oder hängen die neuen Dateien einfach ans Ende der Liste an?
Antwort1
Es gibt viele verschiedene Dateisystemformate und sie machen unterschiedliche Kompromisse hinsichtlich der Leistung in verschiedenen Szenarien (große Verzeichnisse vs. kleine Verzeichnisse, Lesen vs. Schreiben, gleichzeitiger Zugriff, …), der Einfachheit des Designs (Wahrscheinlichkeit von Fehlern, Entwicklungsaufwand, …), des Festplatten-Overheads (für andere Dinge als Dateiinhalte verwendeter Speicherplatz) usw.
Ältere Dateisysteme (zBUFS, FFS,ext2, Originalext3, …) neigen dazu, Verzeichnisse als Array von Einträgen zu speichern (jeder Eintrag enthält einen Dateinamen, eine Inode-Nummer und möglicherweise einige zusätzliche Metadaten) und eine lineare Suche durchzuführen. Neue Dateien werden beim ersten freien Eintrag im Array hinzugefügt; wenn kein freier Eintrag vorhanden ist, wird das Array zunächst vergrößert. Dies führt bei großen Verzeichnissen zu schlechter Performance.
Neuere Dateisysteme (zBext3mit der dir_indexOption,ext4,zfs,btrfs,Reiserfs,HFS,HFS+, …) neigen dazu, Verzeichnisse als Datenstruktur mit logarithmischer Zeitsuche, einer Art ausgewogenem Suchbaum, Hash-Tabelle oder einer Kombination aus beidem (ausgewogener Suchbaum von Hashes) zu speichern – typischerweise eine Variante einesB-Baum. Dadurch wird der Dateisystemcode komplexer, die Leistung bleibt aber bei großen Verzeichnissen gut.
Antwort2
Die Nummer heißtInode. Ext4, einer der beliebtesten Linux-Dateisystemtypen, verwendet einen Hash-Baum, siehekernel.org - Ext4-Festplattenlayout.
Weitere Einzelheiten zu Hash Trees finden Sie unterWikipedia.
Antwort3
Dies hängt vom Dateisystem ab. Vor langer Zeit war das Unix-Verzeichnis im Wesentlichen eine Datei, die aus 16-Byte-Datensätzen bestand, zwei Bytes für die interne Nummer und 14 Bytes für den Dateinamen. Dies ist der Grund für die frühere Beschränkung auf 14 Zeichen für Dateinamen. Die Datensätze waren nicht sortiert, sodass eine lineare Suche in der Datei erforderlich war.
Modernere Dateisysteme wie Ext4 von Linux verfügen über eine Hash-Tabelle, um die Suche zu beschleunigen.
Antwort4
Pedant-Alarm: Die Beschreibung ist nicht vollständig. Dateinamen können nicht nur als Annehmlichkeit für Benutzer beschrieben werden. Dateinamen haben sich alsäußerstwichtig in Unix-basierten Systemen.
Inode-Nummern können keine Bedeutung haben, da sie vom Dateisystemmodul ausgewählt werden. Ursprünglich identifizierten sie einen Steckplatz in der auf der Festplatte gespeicherten Inode-Tabelle. Die anderen Teile des Systems müssen auf Dateien zugreifen, die eine bestimmte Bedeutung haben, z. B. /dev/tty1oder /etc/passwd.
Ohne Sie an ein bestimmtes Wort zu binden, ist „Komfort“ zu trivial, um den Mechanismus zu beschreiben, der verwendet wird, um die Benutzeroberfläche für die Auswahl von Befehlen wie catoder ednach Namen bereitzustellen.
Wenn es keine Verzeichnisse mit Dateinamen gäbe, müssten Sie sehr bald einige sehr ähnliche Register mit Namen für die Inode-Nummern erfinden, um diese Verwendungen zu unterstützen.
Auch die Verzeichniseinträge .und ..haben eine spezielle Bedeutung. Virtuelle Dateisysteme wie procgeben ihre eigene Bedeutung durch Dateinamen an, um beispielsweise /proc/1/commInformationen über Prozess 1 bereitzustellen. Das VFS ermöglicht auch die Verwendung verschiedener Dateisysteme, die nicht auf Unix basieren müssen und möglicherweise nicht mit dem exakt gleichen Konzept von Inode-Nummern arbeiten.
ZFS scheint zu denken, dass sowohl Dateinamen als auch Inode-Metadaten, wie etwa Berechtigungen, in eine separate Ebene gehören. Mir ist noch nicht klar, welchen Vorteil das bietet. Es scheint eher eine Möglichkeit zu sein, verschiedene Leistungsregler für dateiäquivalente Objekte bereitzustellen, wenn sie zum Speichern verschachtelter Dateisysteme verwendet werden.
Außerdem können Benutzer Dateien im Allgemeinen nicht anhand der Inode-Nummer öffnen. Wenn dies möglich wäre, könnten Sie den Zugriff auf eine Datei nicht über die Berechtigungen des enthaltenden Verzeichnisses steuern...
Vielleicht kann man den letzten Punkt auch so betrachten, dass es sich um eine Funktion von Verzeichnissen handelt. Das ganze Prinzip eines Verzeichnisses besteht darin, Dateinamen zuzuordnen. Ohne diese Funktion haben sie also keine wirkliche Wirkung.
Moment, sagen Sie, sie hätten immer noch eine Wirkung als Container für Verweise auf Dateien, auch bekannt als „Hardlinks“. Sie können Dateien in mehreren Verzeichnissen auflisten; das Entfernen einer Datei aus einem Verzeichnis ( unlink) löscht sie nicht wirklich, wenn sie noch in einem anderen Verzeichnis verbleibt. Hardlinks sind ein interessanter Teil der Unix-Implementierung, aber meines Wissens nach haben sie nie wirklich einen Nutzen gehabt! Sie werden im Allgemeinen nur als Gelegenheit zur Verwirrung betrachtet. Ein Beispiel für die Offenlegung eines Implementierungsdetails, weil es dadurch sehr einfach wurde, interessante Funktionen bereitzustellen, ohne wirklich zu überlegen, ob die Funktion notwendig war. Ähnlich wie der „Milliarden-Dollar-Fehler“, obwohl dieser spezielle Konstruktionsfehler nicht so gefährlich war.
Dennoch ist es erwähnenswert, wie Verzeichnisse die Existenz der darin enthaltenen Dateien garantieren. Wenn Sie ein anderes System zur Identifizierung von Dateien implementieren möchten, müssen Sie die Möglichkeit in Betracht ziehen, dass beim Löschen einer Datei ein Eintrag übrig bleibt, der auf eine nicht vorhandene Datei verweist, oder sogar auf eine neue und nicht verwandte Datei, der später dieselbe Inode-Nummer zugewiesen wurde.