Thema: Ramdisk

[Programm Noob]

Moin

Nach dem Paging nun so gut wie überstanden ist kommt die nächste Frage, wie kann ich gut eine Ramdisk erstellen und gut drauf zugreifen. Mir wäre Fat auf der Ramdisk am liebsten. Ist das realisierbar? Habt ihr bessere Vorschläge?

Programm Noob

[erik.vikinger]

Hallo,


Das folgende gilt nur wenn Du eine richtige RAM-Disk zum lesen und beschreiben willst, wenn Du nur irgendetwas brauchst das eine Art Init-ROM-Disk darstellt gibt es ne Menge anderer guter Wege.

wie kann ich gut eine Ramdisk erstellen

Falls Du einen Monolithen entwickelst dann schau doch mal wie Linux das macht, also wie tmpfs funktioniert. Falls Du einen Micro-Kernel baust dann sollte die RAM-Disk als ganz normaler User-Mode-Prozess laufen und sich an Dein VFS als File-System anmelden.

und gut drauf zugreifen

Das hängt davon ab wie Dein VFS arbeitet.

Mir wäre Fat auf der Ramdisk am liebsten

Das heist Du möchtest ein Block-Device bestimmter Größe simulieren? Kann man machen aber davon würde ich eher abraten. Das belegt ja dann immer den vollen Speicher auch wenn kaum Daten drauf abgelegt sind und lässt sich auch nicht dynamisch vergrößern oder verkleinern.

Habt ihr bessere Vorschläge?

Falls Du ein Micro-Kernel-OS entwickelst würde ich vorschlagen das Du dafür einfach dynamische Listen (in C++ am einfachsten vector) und malloc/realloc nimmst. Ein Verzeichnis ist eine Liste von Descriptoren und jeder Descriptor beschreibt entweder eine Datei oder ein Verzeichnis. Die Descriptoren sollte immer gelich Groß sein damit die Liste möglichst simpel sein kann. Dateien sind einfach per malloc allozierte Speicherbereiche (wenn Du die Größe der Datei ändern willst nimmst Du realloc, da musst Du Dich noch nicht mal um das umkopieren der Daten kümmern). Diese Speicherbereiche solltest Du aber am besten immer auf das nächste Vielfache einer Page-Größe aufrunden und das malloc entsprechen optimieren. Für die Funktionen create/read/write/resize/delete sollte ein geübter C Programmierer höchstens 2 oder 3 Tage brauchen, komplexer wird es wenn dann noch sowas wie Zeitstempel (für Erstellung/letzte Modifikation/letzten Zugriff) dazu kommen oder Extras wie Sparse-Files unterstützt werden sollen. Der Vorteil dieses Konzepts ist das Du nicht mehr RAM als nötig verbrauchst und die simpelste Version sehr schnell getippt ist. Was noch fehlt sind globale Variablen in denen Du die Anzahl der Dateien/Verzeichnisse, die aktuelle Gesamt-Größe aller Dateien und den (durch aufrunden) tatsächlich verbrauchten Speicher mitführst. Damit kannst Du auch problemlos ein vorgegebenes (flexibles) Maximum an Speicherverbrauch einhalten (um Disk-Voll-Error zurückmelden zu können).
Nach dieser Methode werde ich wahrscheinlich meine erste RAM-Disk bauen.


Wenn jemand eine bessere Idee hat würde ich es auch sehr begrüßen diese hier lesen zu können.


Grüße
Erik

[kevin]

Das heist Du möchtest ein Block-Device bestimmter Größe simulieren? Kann man machen aber davon würde ich eher abraten. Das belegt ja dann immer den vollen Speicher auch wenn kaum Daten drauf abgelegt sind und lässt sich auch nicht dynamisch vergrößern oder verkleinern.

Das kommt drauf an, ob man die Ramdisk besonders ungeschickt implementiert. Zum einen besteht natürlich immer die Möglichkeit, direkt in der Ramdisk den Speicher in gewissen Blockgrößen zu verwalten und neuen Speicher nur dann anzufordern, wenn er tatsächlich benötigt wird. Zum anderen passiert das in Systemen wie Linux ganz automatisch, wenn man Speicher anfordert (erstmal COW auf eine Page mit Nullen).

Aber ja, die Frage, ob man ein Blockgerät oder ein Dateisystem simulieren möchte, ist natürlich die allererste Frage in Sachen Ramdisk.

In tyndur haben wir sowohl eine Ramdisk auf Dateisystembasis (die allerdings im Moment nicht wirklich benutzt wird...) als auch den ramoverlay-Service, der auf Blockebene arbeitet. Letzterer ist was wir benutzen, um auf Live-CDs temporären Schreibzugriff zu erlauben.

[erik.vikinger]

Hallo,

Zum einen besteht natürlich immer die Möglichkeit, direkt in der Ramdisk den Speicher in gewissen Blockgrößen zu verwalten und neuen Speicher nur dann anzufordern, wenn er tatsächlich benötigt wird.

Dazu muss aber der RAM-Disk-Simulator auch erkennen welche Sektoren nicht mehr benötigt werden um diese wieder frei geben zu können. Dazu muss er dann aber das verwendete Datei-System gut kennen oder das Datei-System muss das ATA-TRIM-Kommando unterstützen. Wenn beides nicht der Fall ist würde die RAM-Disk nie wieder "ausatmen" können und das ist IMHO ein KO-Kriterium.


Grüße
Erik

[Svenska]

Hallo,

Blockbasierte Ramdisks einer bestimmten Größe belegen immer diese Größe. Oder weniger, wenn die entsprechenden Blöcke nie benutzt wurden. Eine Ramdisk atmet also nie aus. Das ist designtechnisch so vorgegeben, aber immernoch besser, als den Speicher grundsätzlich zu belegen.

Gruß

[erik.vikinger]

Hallo,

Eine Ramdisk atmet also nie aus. Das ist designtechnisch so vorgegeben, aber immernoch besser, als den Speicher grundsätzlich zu belegen.

Das ist und bleibt aus meiner Sicht ein absolutes KO-Kriterium für so eine Block-Device basierte RAM-Disk. Ich glaube auch nicht das z.B. tmpfs von Linux so arbeitet. Die könnte man auch nicht dynamisch in der Größe verändern. Für ein sehr lang laufendes System ist es unerlässlich das nicht mehr benötigter Speicher immer ordnungsgemäß freigeben wird, alles andere bedeutet designtechnisch beschränkte Laufzeit!
Ich denke eine richtige File-System basierte RAM-Disk ist nicht so viel komplexer zu programmieren und daher immer vorzuziehen. Und gewiss auch schneller weil weniger Treiberschichten nötig sind.


Edit: RW-Overlays für RO-Blockdevices sind was anderes als richtige RAM-Disks.


Grüße
Erik

[Svenska]

Hallo,

tmpfs ist keine Ramdisk, sondern ein Dateisystem, welches als Backend virtuellen Speicher benutzt. Ramdisks sind /dev/ram* oder die initrd (nicht initramfs!). Beide Methoden sind allerdings inzwischen veraltet.

Bei deiner Argumentation vergisst du, dass die Größe einer Ramdisk bereits bei ihrer Erstellung vorgegeben sein muss (nicht die maximale Größe!), daher kann sie nicht wachsen und/oder schrumpfen. Vergleiche es mit RAMDRIVE.SYS.

Wenn du bereits Blockgeräte und Dateisysteme unterstützt (und auch erzeugen kannst!), dann ist eine Ramdisk extrem einfach zu implementieren - kmalloc() ausführen und als Blockdevice anmelden, der Rest geht dann von alleine. Eine VFS-basierte Ramdisk ist ein neues Dateisystem und daher z.B. nicht geeignet, um den FAT-Treiber zu testen.

Daher: Eine Ramdisk atmet nie aus. Was du meinst, ist ein Dateisystem, welches alle Daten im Speicher hält.

Gruß

[erik.vikinger]

Hallo,

Beide Methoden sind allerdings inzwischen veraltet.

Aus gutem Grund möchte ich meinen.

Daher: Eine Ramdisk atmet nie aus. Was du meinst, ist ein Dateisystem, welches alle Daten im Speicher hält.

Okay, begriffen.
Wir sind damit eindeutig beim Haarespalten angekommen.
Ich persönlich bevorzuge trotzdem das RAM-Filesystem. Wegen dem ausatmen und weil man dynamisch resizen (einfach das Maximum ändern) kann.

Wer seinen FAT-Treiber testen will kann auch Disketten nehmen oder ne HDD in einem der vielen und beliebten PC-Simulatoren/Emulatoren.


Grüße
Erik

[Svenska]

Naja, die initrd wurde sehr lange verwendet - da extrem einfach, leicht wartbar und man kann sie (als Ganzes) auch wieder freigeben (dann belegt sie keinen Speicher). Außerdem kann man mit Ramdisks halt wunderbar seine Dateisysteme testen, daher gibt es sie noch.

Außerdem kann man einfach ein Stück NOR-Flash in den Adressraum mappen, so tun als wäre es eine Ramdisk und dann XIP (eXecute In Place) damit machen. Ist schon recht sinnvoll, so eine einfache Struktur.

Initramfs setzt auf tmpfs auf und entpackt ein cpio-Archiv dorthin und bootet dann ab da weiter. Das ist etwas komplizierter, aber inzwischen gibt es die Infrastruktur dafür. Du kannst übrigens tmpfs auch aus dem Kernel entfernen, dann bekommst du ramfs - welches direktes Kernel-VFS auf einer "richtigen" Ramdisk ist. Sinnvoll, wenn das System keine MMU hat, weil du dann effizienter im Block arbeiten kannst.

Gruß