Begriff

Tmpfs Mount (RAM Disk)

Linux Container S2

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Normalerweise schreiben Programme auf die Festplatte (HDD/SSD). Das ist langsam und überlebt einen Neustart. Manchmal willst du das Gegenteil:

Es soll extrem schnell sein (Cache).
Es soll sofort weg sein, wenn der Strom ausgeht (Passwörter). Dafür gibt es tmpfs. Du mountest einen Teil des RAMs (Arbeitsspeicher) als "Ordner". /mnt/ramdisk. Alles, was du da reinschreibst, landet nie auf dem Datenträger.

Merksatz: Ein temporäres Dateisystem, das Daten im volatilen Arbeitsspeicher speichert, statt auf persistenten Speichermedien, um Hochgeschwindigkeitszugriff oder Datensicherheit (Spurlosigkeit) zu gewährleisten.

Docker: docker run --tmpfs /app/cache nginx K8s:

volumes:
- name: secrets
  emptyDir:
    medium: Memory

Wenn der Container stoppt, sind die Daten sofort weg. Keine "Undelete" Tools können sie retten.

1. Security (Secrets)

Warum nutzen Vault oder K8s Secrets tmpfs? Festplatten sind verräterisch. Selbst nach dem Löschen sind magnetische Spuren da. SSD Controller machen "Wear Leveling" und kopieren Daten im Hintergrund. Wenn du ein Passwort auf Disk schreibst, ist es schwer, es wirklich zu löschen. Im RAM ist es physikalisch weg, sobald der Strom weg ist (Cold Boot Attack mal ausgenommen).

2. OOM Killer Gefahr

Das tmpfs teilt sich den RAM mit den Programmen. Wenn du 10GB RAM hast und 9GB Dateien ins tmpfs schreibst... Startet der OOM Killer (Out Of Memory) und tötet deine Datenbank. Docker erlaubt tmpfs-size Limit. In K8s zählt emptyDir: Memory gegen das memory limit des Pods. Wenn Cache voll -> Pod Crash.

3. Swap Interaktion

Achtung Falle! Linux lagert RAM auf die Festplatte aus (Swap), wenn er voll ist. Auch tmpfs-Inhalte können im Swap landen! Dann stehen deine "sicheren" Passwörter plötzlich doch auf der Festplatte. Sicherheits-Systeme müssen Swap deaktivieren (swapoff -a), um echte Vertraulichkeit zu garantieren.

Cgroups Memory Enforcement (Der Tod von Außen)

Das wichtigste Missverständnis bei Linux-Containern: Ein Container ist ohnehin nicht grenzenlos, er ist in cgroups (Control Groups) des Kernels eingesperrt. Das Memory-Limit (z.B. limit=500M in Docker) inkludiert zwingend tmpfs-Mounts (Anonymous Pages). Schreibt ein In-Memory-Redis im Backend also fleißig 400MB Daten in das Tmpfs und der Java-Garbage-Collector fordert danach 150MB aus der Heap-Reservation an, sprengt die Gesamt-Allokation das cgroup Limit (550 > 500). Der Kernel-Reaper killt per SIGKILL sofort den Hauptprozess, ohne Vorwarnung; die Diagnose "Warum?" aus den Crash-Logs ist fast unmöglich zu beantworten, da das Tmpfs nirgendwo dediziert limitiert war.

Inode Erschöpfung

Man denkt, im RAM gibt es nur das Platz-Problem. Falsch: Auch /tmp oder tmpfs haben einen Inode Table. Wenn man einen Tmpfs-Mount mit 2GB anlegt, errechnet der Kernel intern ein Limit an Datei-IDs (Inodes). Wenn eine fehlerhafte App (Cache) Millionen von 0-Byte großen Temp-Dateien im tmpfs abwirft, fressen sie nicht dein Volumen (0 MB), aber du fährst auf eine dicke "No space left on device"-Fehlermeldung auf. Die Inodes sind zu 100% erschöpft. Bei hochfrequenten Session-Stores muss der Mountbefehl z.B. mittels tmpfs --size=1G,nr_inodes=1M präemptive Meta-Limits definiert bekommen.

/dev/shm und Container Isolation

In Linux ist /dev/shm technisch ebenfalls ein tmpfs. Datenbanken wie Oracle, PostgreSQL oder Message Broker (ZeroMQ) feuern Memory-Graphen via POSIX Shared Memory IPC (Inter-Process Communication) hin und her, um Puffer zu teilen ohne Loopback-Interfaces zu bemühen. Docker nutzt per Default strenge IPC Isolation-Namespaces. Kein Container sieht das Shared Memory (/dev/shm) des Nachbarn. Das shm-size Profil bleibt auf winzigen 64MB Default-Wert gedrosselt, was bei parallelem Data-Crunching in PyTorch massiv fehlschlägt und sofort in Bus Error Kernel-Segfaults crashed. Manuelles Resizing (via --shm-size=2g Laufzeitparameter) rettet oft Stunden verzweifeltes Debugging an Machine Learning Containern.

Quick-Check

Performance Gewinn?
Dramatisch. RAM ist 100x schneller als SSD. Latenz im Nanosekunden-Bereich. Perfekt für temporäre Compile-Dateien oder Session-Caches.
Unterschied zu Ramdisk?
Altmodische Ramdisks reservierten fix 1GB RAM. Wenn leer, war der RAM trotzdem weg. tmpfs wächst und schrumpft dynamisch. Es belegt nur so viel RAM, wie Dateien drin sind.
/dev/shm?
Shared Memory. Ein Standard-tmpfs in Linux, das Prozesse nutzen, um Speicherbereiche zu teilen (Inter Process Communication). Docker container haben oft ein zu kleines /dev/shm (64MB), was Chrome/PyTorch crashen lässt. Mount es größer!