Ein Laufwerk wird mir im Dateimanager leider nicht angezeigt und wenn
ich über das Dateisystem zum Ordner /tmp/ramdisk navigiere und versuche,
dort Dateien einzufügen, bekomme ich die Fehlermeldung, dass am Ziel
nicht genügend Platz frei ist (0 Bytes verfügbar).
Wie kann ich die RAM Disk einrichten und ohne Reboot auch im
Dateimanager als Laufwerk benutzen?
Vielen Dank und viele Grüße
Albert
Was zeigt denn df an?
ramfs sollte man eigentlich eher nicht benutzen, denn es hat den
Nachteil, dass es wachsen kann, bis der RAM-Speicher voll ist und der
Rechner unbenutzbar wird. Eine mount-Option "size" gibt es dafür nicht.
Besser tmpfs, bei dem das geht.
Das mit dem Mountpoint /media war schon mal hilfreich. Mit den
Dateimanagern scheint es Probleme mit RAMFS zu geben. Anders als bei
MATE kann ich unter XFCE die Fehlermeldung mit "Trotzdem kopieren"
übergehen. Vielleicht handelt es sich ja um eine schlecht kommunizierte
Barriere, damit User das System nicht versehentlich durch Überschreiten
des Speichers zum Absturz bringen. Mit dem Terminal geht es als user
übrigens einwandfrei.
df zeigt bei mir keine eingebundenen Laufwerke mit RAMFS an, es werden
nur die mit TMPFS korrekt angezeigt und die lassen sich auch normal mit
den Dateimanagern nutzen.
Kann man bei TMPFS sicherstellen, dass nur im RAM gearbeitet wird und
nicht z.B. der swap genutzt wird?
Vielen Dank für eure Hilfe
Albert
Albert schrieb:> Kann man bei TMPFS sicherstellen, dass nur im RAM gearbeitet wird und> nicht z.B. der swap genutzt wird?
ist nicht Zielführend, wobei das (unbekannte) Ziel relativ egal ist.
Was hilft es dir, wenn bei Speicherknappheit zwar die Daten im RAM
gelockt sind, aber dein Anwendungsprogramm dafür praktisch von HDD und
nicht aus dem RAM läuft?
Zum Vermeiden von Paging auf die Platte: Großzügig bemessenes
"zram-swap"(*), HDD-Swap abschalten oder mit sehr niedriger Prio, und an
der vm-"swappiness" drehen (nahe bei, aber größer als 0).
*) debian: "zram-tools" installieren, config in /etc/default/zramswap
Warum brauchst Du überhaupt eine Ramdisk? Im übrigen sollte /tmp bei
Debian standardmäßig schon eine Ramdisk (tmpfs) sein, da das bei systemd
schon lange die Standard-Einstellung ist.
Soweit ich das in meinen Docs zum Raspi sehe, musst Du erst den
Mountpoint im Filesystem erzeugen
sudo mkdir /tmp/ramdisk
und denn in /etc/fstab
tmpfs /tmp/ramdisk tmpfs nodev,nosuid,relatime,size=256M 0 0
dann mounten mit
sudo mount -a
Beim Neustart wird es automatisch gemountet.
Andreas M. schrieb:> Warum brauchst Du überhaupt eine Ramdisk?
Ich hab zum Beispiel auf den Raspi eine, in der Kamerabilder und Daten
geloggt werden, auf die andere Programme zugreifen, die aber nicht
dauerhaft gehalten werden müssen.
Da werden Snapshots der Kamera gespeichert, um daraus einen
Zeitraffer-Film zu machen. Danach können die wieder weg.
Εrnst B. schrieb:> Zum Vermeiden von Paging auf die Platte: Großzügig bemessenes> "zram-swap"(*), HDD-Swap abschalten oder mit sehr niedriger Prio, und an> der vm-"swappiness" drehen (nahe bei, aber größer als 0).
Verstehe ich das richtig, dass man mit genug RAM nur den HDD-Swap
abschalten muss? Laut "swapon --show" gibt es bei mir nur die bei der
Installation angelegte Swap-Partition sdb3. Reicht also ein "swapoff
/dev/sdb3" direkt vor dem Mounten des tmpfs Laufwerks? Die vm.swapiness
scheint das Verhalten zu beeinflussen, wann geswapt wird, aber es kann
vermutlich nur der eingerichtete HDD-Swap (z.B. /dev/sdb3) genutzt
werden?
Karl K. schrieb:> sudo mkdir /tmp/ramdiskAndreas M. schrieb:> Im übrigen sollte /tmp bei> Debian standardmäßig schon eine Ramdisk (tmpfs) sein, da das bei systemd> schon lange die Standard-Einstellung ist.
Mit /tmp erscheinen die Laufwerke nur nicht im Dateimanager, daher ja
der Wechsel auf /media.
Vielen Dank für eure Tipps
Albert
Wenn kein Swap da ist, kann nicht geswappt werden.
Wann du das abschaltest, ob du das tmpfs vorher oder nachher mountest
ist egal.
Wenn du den Swap später wieder einschaltest, kann er auch wieder
verwendet werden. Auch hier ist der mount-zeitpunkt des tmpfs egal.
Aber die Plan das Swapping für die Ramdisk abzuschalten deutet für mich
erstmal darauf hin, dass sich bei dir irgendeine fehlerhafte fixe Idee
festgesetzt hat (*), vermutlich wegen Unverständnis der
Linux-Speicherverwaltung.
Albert schrieb:> mit genug RAM
swappt er die Ramdisk sowieso nicht auf die Platte. Du hast also nicht
genug Ram. Dann ist es aber schlecht, ihm das Swapping generell zu
verbieten.
Deshalb mein Vorschlag mit dem ZRam und dem beibehalten der HDD als
"last Resort".
Edit (*): Soll das vielleicht irgendein Sicherheits-Feature werden, dass
die User ihren Pr0n nicht auf der Festplatte verewigen? Da würde ich dir
eher zu einer verschüsselten Swap-Partition raten (+verschlüsseltes
Root+Home natürlich).
Albert schrieb:> Verstehe ich das richtig, dass man mit genug RAM nur den HDD-Swap> abschalten muss?
Nö, warum sollte man das müssen? Wenn man genug RAM hat, wird sowieso
nicht ausgelagert.
Und wie Ernst schon schreibt:
Εrnst B. schrieb:> Was hilft es dir, wenn bei Speicherknappheit zwar die Daten im RAM> gelockt sind, aber dein Anwendungsprogramm dafür praktisch von HDD und> nicht aus dem RAM läuft?
Falls nicht genug RAM da ist, willst du nicht, dass er die Daten der
RAM-Disk zwingend dort drin hält. Mit eingeschaltetem Swap würde das
nämlich bedeuten, dass die Programme ausgelagert und damit elends
langsam ausgeführt werden, so dass deine superschnelle RAM-Disk nix mehr
bringt. Und ohne Swap kommt der OOM-Killer und schießt dein Programm
einfach ab, wenn mehr Platz benötigt wird. Also lass das System sich
lieber darum kümmern.
Einzig die schon angesprochene swappiness umzustellen, könnte sich
lohnen, um dem System Präferenzen zwischen Festplatten-Cache und
Auslagerung zu geben.
Albert schrieb:> Mit /tmp erscheinen die Laufwerke nur nicht im Dateimanager, daher ja> der Wechsel auf /media.
Das Konzept "Laufwerke" existiert unter Linux nicht. Das unter /media
gemountete Dateisysteme zufälligerweise in Deinem Linux-Dateimanager
explizit erscheinen ist ein spezifisches Verhalten Deines Dateimanagers.
Dieses lässt sich aber nicht so ohne weiteres auf jeglichen
Linux-Dateimanager verallgemeinern. (Es gibt unter Linux nicht "den"
Dateimanager)
Was genau willst Du eigentlich damit erreichen? Für was willst Du die
Ramdisk benutzen bzw. warum brauchst du unbedingt eine ramdisk dafür?
Warum muss das "im Dateimanager erscheinen"?
Andreas M. schrieb:> Albert schrieb:>> Mit /tmp erscheinen die Laufwerke nur nicht im Dateimanager, daher ja>> der Wechsel auf /media.>> Das Konzept "Laufwerke" existiert unter Linux nicht. Das unter /media> gemountete Dateisysteme zufälligerweise in Deinem Linux-Dateimanager> explizit erscheinen ist ein spezifisches Verhalten Deines Dateimanagers.
/media ist normalerweise für Wechselmedien (per pmount oder einem
graphischen Pendant) gedacht.
> Dieses lässt sich aber nicht so ohne weiteres auf jeglichen> Linux-Dateimanager verallgemeinern. (Es gibt unter Linux nicht "den"> Dateimanager)
Ja. Meiner zeigt auch mount-Points außerhalb von /media an. Ob er Dinge
in /tmp auch anzeigen würde, weiß ich aber nicht. Für von Hand temporär
gemountete Dateisysteme nutze ich in der Regel /mnt.
> Was genau willst Du eigentlich damit erreichen? Für was willst Du die> Ramdisk benutzen bzw. warum brauchst du unbedingt eine ramdisk dafür?> Warum muss das "im Dateimanager erscheinen"?
Für mich wäre die Frage, warum es so unbedingt nicht auslagern darf,
selbst wenn das bedeutet, dass die Stabilität des Systems gefährdet ist.
🐧 DPA 🐧 schrieb:> Rolf M. schrieb:>> Wenn man genug RAM hat, wird sowieso nicht ausgelagert.>> Hängt das nicht von der eingestellten swappiness ab?
Es hängt von der Nutzung des Platten-Cache und der swappiness ab.
Kopiert man viele Dateien umher, wird ggf. Auslagerung betrieben, um
mehr Platz für den Cache zu bekommen. Mit der swappiness kann ich
steuern, wie sehr er das macht. swappiness=0 bedeutet, erst dann
auslagern, wenn's gar nicht anders geht. Ich würde dann zumindest das
nehmen, statt swap ganz abzuschalten.
Eine RAM-Disk braucht man heutzutage nicht mehr. Das System verwaltet eh
allen freien RAM als Cache, d.h. schreibt dort hinein. Erst wenn nix
weiter zu tun ist, wird auf die SSD geschrieben. Man spürt also keinen
Unterschied zwischen RAM-Disk und SSD.
Eine RAM-Disk braucht man nur, wenn man aus Sicherheitsgründen nichts
dauerhaft gespeichert haben will.
Peter D. schrieb:> Eine RAM-Disk braucht man nur, wenn man aus Sicherheitsgründen nichts> dauerhaft gespeichert haben will.
Oder wenn man es mit einem schreibschwachen Medium wie einer µSD-Card zu
tun hat, also bei Raspberry & Co.
Moin,
Peter D. schrieb:> Eine RAM-Disk braucht man heutzutage nicht mehr. Das System verwaltet eh> allen freien RAM als Cache, d.h. schreibt dort hinein. Erst wenn nix> weiter zu tun ist, wird auf die SSD geschrieben. Man spürt also keinen> Unterschied zwischen RAM-Disk und SSD.> Eine RAM-Disk braucht man nur, wenn man aus Sicherheitsgründen nichts> dauerhaft gespeichert haben will.
Das wäre mir neu. Ja, sowohl Linux als auch Windows cachen massiv. Bei
Linux wird der komplette freie RAM für den Cache benutzt, um bereits
angeforderte Daten weiterhin vorzuhalten oder spekulativ vorauszulesen.
Aber Linux (und Windows AFAIK auch) hat mit voller Absicht keinen
Schreibcache im RAM, der beschleunigend wirkt (writeback). Standardmäßig
wird zwar ins RAM geschrieben, zeitgleich aber auf Platte. Und "fertig"
bekommt ein Programm erst gemeldet, wenn die Daten auf der Platte
angekommen sind (writethrough).
Ja, einige Dinge werden je nach Dateisystem zu Transaktionen
zusammengefasst geschrieben. Und einige Dateisysteme schreiben
regelmäßig aktualisierte Daten/Metadaten erst aller xx ms, um die
Schreiblast zu reduzieren. Beides ist aber explizit kein Schreibcache
der erst schreibt "wenn nichts zu tun ist".
Im Gegenteil, Linux macht sogar einige Klimmzüge um den in HDD/SSD
integrierten Schreibcache hart umgehen zu können (barriers etc.), wenn
Daten des Dateisystems geschrieben werden sollen, damit die
Fertigmeldung auch wirklich "feritg" bedeutet.
Beides kann man je nach GUI bei langen und großen USB-Schreibzugriffen
beobachten: Der Start des Kopierens ist rasend schnell (hunderte MB/s),
sinkt aber irgendwann auf die Geschwindigkeit des Mediums ab (99%
fertig). Der Kopiervorgang wird abgeschlossen, wenn auch das letzte Byte
auf dem Medium ist.
LOL schrieb:> Aber Linux (und Windows AFAIK auch) hat mit voller Absicht keinen> Schreibcache im RAM, der beschleunigend wirkt (writeback).
Du kannst bei Linux exakt einstellen, wieviele KB wie lange im
Schreibcache vorgehalten werden dürfen, bevor ein erzwungener Writeback
auf die Platte erfolgt.
vm.dirty_writeback_centisecs, dirty_background_bytes, dirty_ratio usw.
Nur wenn die Applikation (z.B. Datenbanken) es explizit anfordert, wird
auf den endgültigen Abschluss der Schreiboperation gewartet.
LOL schrieb:> Beides kann man je nach GUI bei langen und großen USB-Schreibzugriffen> beobachten: Der Start des Kopierens ist rasend schnell (hunderte MB/s),> sinkt aber irgendwann auf die Geschwindigkeit des Mediums ab (99%> fertig). Der Kopiervorgang wird abgeschlossen, wenn auch das letzte Byte> auf dem Medium ist.
Ich kenne das eher so, dass der USB-Stick munter weiter blinkt, nachdem
das Programm schon lange fertig ist. Und ein unmount braucht auch noch
eine ganze Weile. Erst wenn der auch meldet, dass er fertig ist, sind
die Daten wirklich auf dem Medium angekommen.
Rolf M. schrieb:> LOL schrieb:>> Beides kann man je nach GUI bei langen und großen USB-Schreibzugriffen>> beobachten: Der Start des Kopierens ist rasend schnell (hunderte MB/s),>> sinkt aber irgendwann auf die Geschwindigkeit des Mediums ab (99%>> fertig). Der Kopiervorgang wird abgeschlossen, wenn auch das letzte Byte>> auf dem Medium ist.>> Ich kenne das eher so, dass der USB-Stick munter weiter blinkt, nachdem> das Programm schon lange fertig ist. Und ein unmount braucht auch noch> eine ganze Weile. Erst wenn der auch meldet, dass er fertig ist, sind> die Daten wirklich auf dem Medium angekommen.
Okay, dann macht meine GUI (Xfce/Xubuntu) das anders als deine GUI (oder
Distribution). Ich warte bei 99% immer ewig. Das von dir beschriebene
Verhalten führt zum Schreddern von Daten, wenn $User einfach den Stick
herausreißt. Muss aber eine Programmier/Distributionsentscheidung
gewesen sein, der Kernel verhält sich so wie ich schrieb, es sei denn
man fordert ihn zu Abweichungen auf.
Kann aber u.U. auch am Stick/Medium hängen:
Es gibt irgendein "Mode" bit, welches bei Massenspeichern gesetzt sein
(kann) und den Stick entweder zum Wechseldatenträger oder zur Festplatte
macht. Das verursacht unter Windows subtile Unterschiede beim Booten,
unter Linux u.U. beim Cache-Verhalten.
Aber letztendlich wurde in dem Thread auch schon alles gesagt, was
notwendig ist:
1.)
tmpfs verwenden
2.)
/tmp sollte idealerweise schon tmpfs sein und kann 50% RAM einnehmen
3.)
In /tmp eine weitere Ramdisk zu bauen ist deswegen nicht trivial, da die
Unterverzeichnisse nach dem Neustart erst einmal weg sind und neu
angelegt werden müssen. (Systemd service schreiben, /etc/fstab alleine
reicht nicht).
4.)
/media ist der Ort, den die meisten GUIs nach Wechselmedien durchsuchen.
5.)
Um Schreibzugriffe zu sparen gibt es fertige Lösungen (zram, diverse
Scripte aus der OpenWRT/Raspi Ecke)
Εrnst B. schrieb:> LOL schrieb:>> Aber Linux (und Windows AFAIK auch) hat mit voller Absicht keinen>> Schreibcache im RAM, der beschleunigend wirkt (writeback).>> Du kannst bei Linux exakt einstellen, wieviele KB wie lange im> Schreibcache vorgehalten werden dürfen, bevor ein erzwungener Writeback> auf die Platte erfolgt.>> vm.dirty_writeback_centisecs, dirty_background_bytes, dirty_ratio usw.>> Nur wenn die Applikation (z.B. Datenbanken) es explizit anfordert, wird> auf den endgültigen Abschluss der Schreiboperation gewartet.
Jain? Aber ja, das habe ich übersehen/vergessen, entschuldigung dafür.
Diese Optionen gibt es und die Beschreibung ist richtig, das Verhalten
zeigt sich aber AFAIK nur für "Background Writes", d.h. wenn die
Applikation nicht fsync, sync, O_direct oder fdatasync macht wenn
wirklich geschrieben werden soll.
Das machen alle mir bekannten z.b. beim Speichern in Calc oder beim
beenden - sogar Datenbanken (zumindenst fürs WAL).
Wenn die Anwendung das OS nicht auffordert zu schreiben, müssen die
Daten auch nicht sofort geschrieben werden, das machen andere OS auch
so, ja.
Schreibcache habe ich bei meinem Post als den Quark angesehen, den
Raidkontroller machen, wenn sie Batteriegepuffert Gigabyteweise Daten
vorhalten und mir erzählen, die seinen auf Platte.
Die genannten Optionen sorgen nach meinem Dafürhalten in der Praxis nur
dafür, das alle Daten nach spätestens diesem Zeitraum/Volumen auf der
Platte landen, egal ob angefordert oder nicht. Eine GUI beim Kopieren
auf USB sollte definitiv sync anfordern.
Das ist eher so wie "BUFFERS=99,0" unter DOS, wenn man es nicht massiv
anpasst.
Albert schrieb:> ich versuche unter Debian 10 mit Mate Desktop eine RAM Disk ohne Cache> für normale User einzurichten.
Bitte verzeih', aber warum möchtest Du das tun?
LOL schrieb:> Aber Linux (und Windows AFAIK auch) hat mit voller Absicht *keinen*> Schreibcache im RAM, der beschleunigend wirkt (writeback). Standardmäßig> wird zwar ins RAM geschrieben, zeitgleich aber auf Platte.
Verzeihung, aber ich fürchte, doch. Es sei denn, Du hast Deine Datei mit
speziellen Flags für open(2), wie O_DIRECT geöffnet.
Peter D. schrieb:> Eine RAM-Disk braucht man heutzutage nicht mehr. Das System verwaltet eh> allen freien RAM als Cache, d.h. schreibt dort hinein. Erst wenn nix> weiter zu tun ist, wird auf die SSD geschrieben. Man spürt also keinen> Unterschied zwischen RAM-Disk und SSD.
Das ist falsch. Viele Anwendungen (der Klassiker: Datenbanken) flushen
ihre Daten mehr oder weniger regelmäßig [1]. Und dann werden die auf die
Platte geschrieben, ganz egal wieviel RAM noch frei ist.
In manchen Situationen will man einfach eine RAMdisk haben. Der TE
schildert seine Beweggründe ja nicht, insofern bin ich natürlich genauso
skeptisch wie alle anderen hier.
Und die Fixierung auf irgendeinen verk*ckten Dateimanager und seine
"Laufwerke" ist auch Blödsinn. Nicht zuletzt hat praktisch jedes Linux
unter /dev/shm schon ein tmpfs mit standardmäßig 50% der RAM-Größe
gemounted. Das ist auch für alle Anwender schreibbar.
[1] nicht notwendigerweise mit fsync(). Es gibt auch noch O_DIRECT und
Konsorten.
LOL schrieb:> Linux (und Windows AFAIK auch) hat mit voller Absicht keinen> Schreibcache im RAM, der beschleunigend wirkt (writeback). Standardmäßig> wird zwar ins RAM geschrieben, zeitgleich aber auf Platte. Und "fertig"> bekommt ein Programm erst gemeldet, wenn die Daten auf der Platte> angekommen sind (writethrough).
Das ist in dieser Allgemeinheit falsch. write() und Co. schreiben
erstmal nur in den buffer cache. Erst fsync() bzw. fflush() - je nachdem
auf welcher Ebene du unterwegs bist - schreibt die Daten auf die Platte.
Nur wenn du open() mit dem Flag O_DSYNC machst, umgeht Linux den buffer
cache beim Schreiben. Mit O_DIRECT auch beim Lesen. man 2 open
Thread beobachten
Seitenaufteilung abschalten