Der Unterschied zwischen initrd und initramfs?

Ich denke, Sie haben in allem recht.

Der Unterschied ist leicht zu erkennen, wenn Sie die beim Booten erforderlichen Schritte befolgen:

initrd

• A ramdev Blockgerät erstellt. Es ist ein RAM-basiertes Blockgerät, also eine simulierte Festplatte, die Arbeitsspeicher anstelle von physischen Festplatten verwendet.
• Die initrd Datei wird gelesen und in das Gerät entpackt, als ob Sie zcat initrd | dd of=/dev/ram0 getan hätten oder etwas ähnliches.
• Die initrd enthält ein Abbild eines Dateisystems, sodass Sie das Dateisystem jetzt wie gewohnt einhängen können:mount /dev/ram0 /root . Natürlich benötigen Dateisysteme einen Treiber, wenn Sie also ext2 verwenden, muss der ext2-Treiber im Kernel kompiliert werden.
• Fertig!

initramfs

• A tmpfs ist gemountet:mount -t tmpfs nodev /root . Das tmpfs braucht keinen Treiber, es ist immer on-kernel. Kein Gerät erforderlich, keine zusätzlichen Treiber.
• Der initramfs wird direkt in dieses neue Dateisystem dekomprimiert:zcat initramfs | cpio -i , oder ähnlich.
• Fertig!

Und ja, es heißt immer noch initrd an vielen Stellen obwohl es ein initramfs ist , insbesondere in Bootloadern, da es sich bei ihnen nur um ein BLOB handelt. Der Unterschied wird durch das Betriebssystem beim Booten gemacht.

Dentry- (und Inode-)Cache

Das Dateisystem-Subsystem in Linux hat drei Schichten. Das VFS (virtuelles Dateisystem), das die Schnittstelle für Systemaufrufe implementiert und das Überqueren von Einhängepunkten sowie standardmäßige Berechtigungs- und Grenzwertprüfungen handhabt. Darunter sind die Treiber für einzelne Dateisysteme und diese wiederum Schnittstellen zu Treibern für Blockgeräte (Platten, Speicherkarten usw.; Netzwerkschnittstellen sind Ausnahmen).

Die Schnittstelle zwischen VFS und dem Dateisystem sind mehrere Klassen (es ist einfaches C, also Strukturen, die Zeiger auf Funktionen und dergleichen enthalten, aber es ist konzeptionell eine objektorientierte Schnittstelle). Die drei Hauptklassen sind inode , das ein beliebiges Objekt (Datei oder Verzeichnis) in einem Dateisystem beschreibt, dentry , das den Eintrag in ein Verzeichnis beschreibt und file , die eine von einem Prozess geöffnete Datei beschreibt. Beim Mounten erstellt der Dateisystemtreiber inode und dentry für seinen Stamm und die anderen werden bei Bedarf erstellt, wenn der Prozess auf eine Datei zugreifen möchte und schließlich abgelaufen ist. Das ist ein Dentry- und Inode-Cache.

Ja, es bedeutet, dass für jede geöffnete Datei und jedes Verzeichnis bis hinunter zum Stammverzeichnis inode vorhanden sein muss und dentry Strukturen, die im Kernelspeicher zugeordnet sind und ihn repräsentieren.

Seiten-Cache

Unter Linux wird jede Speicherseite, die Userland-Daten enthält, durch den einheitlichen page dargestellt Struktur. Dadurch kann die Seite entweder als anonym markiert werden (kann in Auslagerungsbereich ausgelagert werden, falls verfügbar) oder mit inode verknüpft werden auf einem Dateisystem (kann in das Dateisystem zurückgeschrieben und erneut aus dem Dateisystem gelesen werden) und es kann Teil einer beliebigen Anzahl von Speicherzuordnungen sein, dh im Adressraum eines Prozesses sichtbar sein. Die Summe aller derzeit im Speicher geladenen Seiten ist der Seitencache.

Die Seiten werden verwendet, um die mmap-Schnittstelle zu implementieren, und während normale Lese- und Schreibsystemaufrufe vom Dateisystem auf andere Weise implementiert werden können, verwendet die Mehrheit der Schnittstellen generische Funktionen, die auch Seiten verwenden. Es gibt generische Funktionen, die, wenn das Lesen einer Datei angefordert wird, Seiten zuweisen und das Dateisystem aufrufen, um sie eine nach der anderen auszufüllen. Für blockgerätebasierte Dateisysteme berechnet es einfach die entsprechenden Adressen und delegiert diese Füllung an den Blockgerätetreiber.

ramdev (ramdisk)

Ramdev ist ein normales Blockgerät. Dies ermöglicht das Schichten eines beliebigen Dateisystems darauf, ist jedoch durch die Blockgeräteschnittstelle eingeschränkt. Und das hat nur Methoden, um eine vom Aufrufer zugewiesene Seite auszufüllen und zurückzuschreiben. Das ist genau das, was für echte Blockgeräte wie Festplatten, Speicherkarten, USB-Massenspeicher und dergleichen benötigt wird, aber für Ramdisk bedeutet dies, dass die Daten zweimal im Speicher vorhanden sind, einmal im Speicher des Ramdev und einmal im Speicher, der vom bereitgestellt wird Anrufer.

Dies ist die alte Art der Implementierung von initrd . Aus Zeiten, als initrd selten und exotisch war.

tmpfs

Tmpfs ist anders. Es ist ein Dummy-Dateisystem. Die Methoden, die es VFS zur Verfügung stellt, sind das absolute Minimum, damit es funktioniert (als solches ist es eine hervorragende Dokumentation dessen, was die Inode-, Dentry- und File-Methoden tun sollten). Dateien existieren nur, wenn es einen entsprechenden Inode und Dentry im Inode-Cache gibt, die erstellt werden, wenn die Datei erstellt wird, und niemals abgelaufen sind, es sei denn, die Datei wird gelöscht. Die Seiten werden Dateien zugeordnet, wenn Daten geschrieben werden, und verhalten sich ansonsten wie anonyme Seiten (Daten können zum Austauschen gespeichert werden, page Strukturen bleiben in Gebrauch, solange die Datei existiert).

Dadurch gibt es keine zusätzlichen Kopien der Daten im Speicher und das Ganze ist viel einfacher und dadurch auch etwas schneller. Es verwendet einfach die Datenstrukturen, die als Cache für jedes andere Dateisystem dienen, als primären Speicher.

Dies ist die neue Art der Implementierung von initrd (initramfs , aber das Bild heißt immer noch nur initrd ).

Auf diese Weise wird auch "posix shared memory" implementiert (was einfach bedeutet, dass tmpfs auf /dev/shm gemountet ist und Anwendungen können dort Dateien erstellen und mmapping; einfach und effizient) und neuerdings sogar /tmp und /run (oder /var/run ) haben häufig tmpfs installiert, insbesondere auf Notebooks, um zu verhindern, dass Festplatten hochgefahren werden müssen, oder um im Fall von SSDs eine gewisse Abnutzung zu vermeiden.