%20als%20tempor%C3%A4res%20Verzeichnis.png)
Ist es eine gute Vorgehensweise, ein Verzeichnis in /run/shm(früher /dev/shm) zu erstellen und dieses wie ein temporäres Verzeichnis für eine Anwendung zu verwenden?
Hintergrund: Ich schreibe Black-Box-Tests für ein Programm, das viel mit Dateien und Verzeichnissen macht. Für jeden Test erstelle ich eine Menge Dateien und Verzeichnisse, führe dann das Programm aus, erstelle den erwarteten Satz von Dateien und Verzeichnissen und führe dann Diff zum Vergleichen aus. Ich habe jetzt ungefähr 40 Tests und sie dauern bereits über 2 Sekunden. In der Hoffnung, die Dinge zu beschleunigen, möchte ich die Tests in einem Verzeichnis auf einer Art Ramdisk ausführen.
Bei meiner Recherche über Ram-Disks stieß ich aufeine Fragemit der Antwort, dass es in Ordnung ist, ein Verzeichnis zu erstellen /dev/shmund dieses als temporäres Verzeichnis zu verwenden. Bei weiteren Recherchen stieß ich jedoch aufeine Wiki-Seitevon Debian mit der Meldung, dass die direkte Verwendung ein Fehler ist /dev/shm. Ich sollte die Funktionen verwenden shm_*. Leider shm_*scheinen die Funktionen für die Verwendung in einem Shell-Skript nicht verfügbar zu sein.
Jetzt bin ich verwirrt. Ist es in Ordnung oder nicht, /run/shm(früher /dev/shm) als temporäres Verzeichnis zu verwenden?
Antwort1
Es ist völlig in Ordnung, ein Verzeichnis in zu verwenden, /runsolange Sie die entsprechenden Rechte dafür haben. In einigen modernen Distributionen /tmpbefindet sich bereits ein virtuelles Dateisystem im Speicher oder ein symbolischer Link zu einem Verzeichnis in /run. Wenn dies bei Ihnen der Fall ist (Sie können dies in überprüfen /etc/fstaboder eingeben ), können Sie als temporäres Verzeichnis mtabverwenden ./tmp
Lassen Sie sich auch nicht von dem Artikel von Debian verwirren. shm_*Funktionen werden verwendet, um gemeinsam genutzte Speichersegmente für die Interprozesskommunikation zu erstellen. Mit diesen Funktionen können Sie ein Speicherfragment zwischen zwei oder mehr Prozessen teilen, damit diese mit denselben Daten kommunizieren oder zusammenarbeiten. Die Prozesse haben das Speichersegment in ihrem eigenen Adressraum angehängt und können dort wie üblich lesen und schreiben. Der Kernel kümmert sich um die Komplexität. Diese Funktionen sind nicht als Shell-Funktionen verfügbar (und wären in einem Shell-Kontext nicht sehr nützlich). Weitere Informationen finden Sie unter man 7 shm_overview. Der Punkt des Artikels ist, dass kein Programm die Pseudodateien, die gemeinsam genutzte Segmente darstellen, direkt verwalten sollte, sondern stattdessen die entsprechenden Funktionen zum Erstellen, Anhängen und Löschen gemeinsam genutzter Speichersegmente verwenden sollte.