Bekanntermaßen ist Arbeitsspeicher auch im Zeitalter von NVMe schneller als die Festplatte. Deshalb wird das Verzeichnis /tmp, das, wie der Name andeutet, temporäre Daten enthält, gerne als tmpfs in den Arbeitsspeicher eingebunden. Bei vielen Distributionen ist das schon lange Standard.
Bei Debian war das bisher nicht der Fall, was sich aber für Debian 13 »Trixie« ändern soll. Bisher musste der Anwender bei Debian hier selbst Hand anlegen. Das Einbinden von/tmpin den Arbeitsspeicher konnte auf mehreren Wegen erreicht werden. Vor der Einführung von systemd wurde dafür eine Zeile in die für das Einhängen von Dateisystemen zuständige Dateifstabeingefügt. Bei systemd gibt es dafür die Mount-Unit tmp.mount.
Bugreport seit 2012
Bereits 2012 erfolgte bei Debian der erste fruchtlos Versuch, es Upstream und anderen Distributionen gleichzutun und temporäre Dateien von der Festplatte zu verbannen. Im Jahr 2020 erfolgte ein weiterer Vorstoß, der jetzt von Luca Boccassi erfolgreich wieder aufgegriffen wurde. Somit wird mit Debian 13 /tmp als tmpfs eingehängt und der Inhalt bei jedem Neustart gelöscht. Des Weiteren wird /var/tmp dann alle 30 Tage durch systemd automatisch aufgeräumt, was bisher nicht geschah. Das Verzeichnis /var/tmp wird laut Filesystem Hierarchy Standard für Programme zur Verfügung gestellt, die temporäre Dateien oder Verzeichnisse benötigen, die zwischen Systemneustarts erhalten bleiben. Daher sind die in/var/tmp gespeicherten Daten beständiger als die Daten in /tmp.
In Debian Unstable und Testing ist die Umstellung bereits vollzogen. Wer bei dem bisherigen Verhalten bleiben möchte, kann dies über das Maskieren der systemd-unit oder über die Konfiguration in /etc/tmpfiles.d tun. Die der Entscheidung vorausgegangene Diskussion fand auf der Entwickler-Mailingliste statt. Ubuntu wird dieser Umstellung folgen, diese aber nicht zurück portieren.
Mich interessiert, wie ich die Umstellung inklusive der Bereinigungsskripte (cronjobs) schon in Debian 12 kompatibel zu Debian 13 durchführen kann.
Gibt es die Pakete schon im Backstore?
Werde ich mir bei Gelegenheit in meiner Test-Trixie VM anschauen.
Das macht auch imho Sinn. Zumal /tmp eh bei jedem Boot neu erstellt wird, dann kann man das gleich in den RAM packen. Bei aktuellen Systemen sind 16 GB RAM im Durchschnitt Standard, da fällt das gar nicht auf. Zumal sich die Größe, Mountpoint etc. simpel per fstab anpassen lassen.
Zu beachten ist, dass man in der fstab nur die Maximalgröße festlegt. Bei Unterbelegung kann das RAM aber auch für andere Zwecke vom Kernel verwendet werden, z.B. cache. Funktioniert automagisch.
Wie der Kernel den RAM managend ist mir bekannt. Eine Mindestgröße für /tmp festzulegen ist auch aus meiner Sicht Quatsch. Weil da eben x GB von vornherein reserviert werden, unabhängig von der tatsächlichen Nutzung.
So wie in der manpage zum tmpfs zu lesen ist, ist die Option size= auch nicht zwingend notwendig. Daher könnte auch das dann den ganzen verfügbaren Speicher, egal ob nun SSD, oder RAM in Beschlag nehmen. Die zu verwendende Maximalgröße kann man als “Überlaufschutz” sehen.
Es besteht ja auch immer noch die Möglichkeit, /tmp ganz auszulagern. Sei es als eigene Partition/HDD/SSD, oder als Netzwerkfreigabe, welche dann gemountet wird. Ob es nun sinnvoll ist, ist dahingestellt. Zum Start ist ja /tmp auch nicht unbedingt notwendig.
Der RAM-Verbrauch dürfte dann vermutlich steigen, oder ?
Nein, der Bereich ist streng begrenzt und abgeschottet, wird mehr benutzt wird die swap verwendet.
Also Normalverbraucher braucht man eh nicht viel mehr wie 4GB Ram. und selbst das wird nicht ausgeschoepft.
Dann frage ich mal so: Was passiert denn wenn ich das nicht manuell anpasse? Ich nutze Debian schon sehr lange, aber viele Sachen gehen auch an mir vorbei. Ich habe beruflich nichts damit zu tun und bin bei vielen Themen auch nicht in der Tiefe. Trotzdem mag ich Debian als Distribution und bin sogar bekennender GNOME User😁. Ich habe erst vor einigen Monaten einen Rechner mit einer NVMe neu aufgesetzt und keine Verzeichnisse angepasst. Bemerke aber nicht, dass dies Nachteile hat. Welche Nachteile hat das nun und was sollte ich tun bzw. muss ich etwas zwingend tun?
Wie wird das mit dem Upgrade nach 13 gelöst werden bei Installationen die nicht händisch angepasst wurden?
Du musst erst mal gar nichts tun. Ich vermute, mit Debian 13 wird das beim Upgrade umgestellt. War in Unstable vor einigen Wochen auch so.
Es passiert garnichts, ob du es nun umgestellt hast oder nicht.
Es ist nur so, das man damit etwas Geschwindigkeit (fuer meine Begriffe kaum messbar aber man macht es halt) 😉
Ich sags mal so, du wirst es eh nicht merken.
Tun musst du garnix, weder jetzt noch spaeter. Es wird quasi nur ein Speicherbereich fuer tmp gesperrt sonst nix.
Frueher hat man dazu ganz trivial Ramlaufwerk gesagt, gibts schon ewig.
Und ist seit der Version 2.4 fest im Kernel als modul tmpfs.
Damit brauchte man kein Laufwerk mehr erstellen sonder nur noch die Einbindung in die fstab machen.
Das faellt nun weg und es wird bei der installation/upgrade mit gemacht.
Deswegen sagte ich das man das automatisch macht. 😉
Herzlichen Dank für die Info. Das ist aber auch das Problem: Themen werden gehypt und der nicht Profi denkt was er gerade falsch macht oder welchen Gefahren er sich aussetzt. Dabei ist alles halb so wild. Auch hier in der Diskussion kommt das Gehühl auf, dass diese Umstellung ganz wichtig ist. Natürlich habe ich von dem Thema am Rande gehört/gelesen, aber das war es auch schon. Nichts wo die Alarmglocken geschrillt hätten. Genau deswegen finde ich Linuxnews so wichtig, weil hier solche Nachrichten immer hoch poppen.
Genau das ist der Grund.
Auch wenn in den letzten x Jahren die Controller auf den Karten in Punkto wear-leveling sehr viel besser als früher geworden sind – wenn einige Schreibzyklen einfach vermieden werden können, klingt das für mich nach einem nobrainer.
Je nachdem, wie die Box eingesetzt wird, sollte man den Geschwindigkeitsgewinn aber auch nicht unterschätzen. Bspw. das Bauen von Software kann erheblich beschleunigt werden, wenn das Arbeitsverzeichnis im Ram liegt.
Alles klar. Habe verstanden wofür und warum das umgestellt werden soll/wird.
Kein potentielles Risiko in Punkto Sicherheit oder akut gefährdetem HW Schaden. Habe auch verstanden, dass mit Debian 13 sich das Thema erledigt hat, da umgestellt wird. Also alles gut am Ende. Sehr aufschlussreich. Danke euch!
Naja hat doch bis dato jeder selbst gemacht, sobald das System installiert ist. Quasi ein todo nach install.
Aber gut, das es jetzt drin ist, obwohl bei Debian nicht notwendig, denn wer Debian nutzt hat auch etwas Ahnung. 😉
Ich bezweifle es. Wer Ahnung hat, nimmt eine vernünftige Distibution.
Debian und Debianbased Distros sind aber am meisten verbreitet. Schon immer. 🙂
Jetzt hab ich aber gleich mal ein paar Fragen.
Was bitte hat ubuntu mit debian zu tun, ausser das es ein Derivat von debian ist?
Debian hat mehr als 400 Derivate, sprich mehr als 400 Distributionen basieren auf Debian.
Fedora Workstation/Silverblue? Welchen gigantischen Desktop sollte das haben, den nicht jede andere Distribution auf dem Planeten auch hat?
Was ist so besonderes da dran?
Ja wer gnome mag. Aber das koennte man auch selbst machen.
Wenn ubuntu das macht, dann ist es doch seine Sache, werden sich schon was dabei gedacht haben.
Was das aber mit debian zu tun hat ist mir unklar.
Uebrigends die meisten Debiannutzer vervenen keinen GnomeDesktop.
Snap verbietet auch jeglichen Zugriff auf /dev.
Versuch so mal, einen UART/TTL Adapter von einem snap aus zu benutzen… Beispielsweise um via Chromium die tasmota web installer.
Deswegen ist snap für mich im privaten Umfeld ein no go. Der komplette daemon wird nach der Installation direkt entfernt.
Mal ehrlich snap und flat sind im Businessbereich absolute no-goes.
Ich bin bei Linux auch eher interessierter Nutzer als Fachmann. Daher eine kurze Frage, Canonical zielt doch mit Ubuntu auch ein Stück weit in Richtung Firmenkunden.
Aber wenn u.a. Snap dafür ein no-go ist, graben sie sich doch genau diese Kunden selbst ab? Oder sehe ich das falsch? Zumal es das ja schon länger gibt.
Warum, wie Du unten schreibst, verbietest Du das sogar in Deiner Firma?
Also nicht verifizierte Pakete verstehe ich, aber z.B. Libreoffice sollte da doch kein Problem sein?
Naja ubuntu ist im Enterpriceranking schon vorn.
Natuerlich mit einer anderen Distribution als sie der Normale ubuntunutzer kennt, gefolgt von Debian,
https://www.openlogic.com/blog/top-enterprise-linux-distributions
Bei mir wird die Software zentral ausgerollt, sprich ich installiere, aktualisiere die Software auf allen Geraeten von zentraler Stelle aus und ggf. mit einem mal. Sprich Du kommst am Mo auf Arbeit schaltest den Rechner ein und er upgraded erst einmal. z.b.
Da braucht Keiner sowas, weil Keiner extra Software braucht.
Das muss so sein, weil wir eine eigene fuer uns speziell zusammengestellte Distribution haben.
Geht natuerlich auch mit anderen Distros.
……………..
unsere Kunden verlangen dies auch teilweise, genau so wie das unsere Software kein aktivx, kein JS etc. verwenden darf. Da gibts immer Anfragen was in der Software nicht voekommen darf.
Deswegen ist auch KI als Programmierhilfe verboten, a kann es zu Lizenseproblemen fuehren und b kann man dadurch auch etwas einschleppen.
Ist nat. fuer Normalnutzer alles uninteressant. 😉
Also ich unterscheide da immer nach Verwendungszweck, welche Distro ich nutze:
Bei Servern: meist Debian, wegen der Stabilität
Bei Desktops: Mageia, Debian, Fedora
Den Linuxanfängern verpasse ich meist Mageia, weil es für jede Konfiguration gute grafische Einrichtungswerkzeuge gibt –> macht es sehr bequem
hmm ok, kann man machen muss man aber nicht.
Um ueberall die gleiche Basis zu haben finde ich es besser nur eine Distro und auf dieser Distrobasierende zu nehmen. Erleichtert unheimlich den Support, da man ja eine gemeinsame Basis hat
ich sag mal nee. Flat hat Sicherheitsprobleme und wer Einheitsbrei haben will, der soll zu mac oder MS gehen, Linux ist anders.
Ich habe das aus Firmensicht betrachtet.
Bei mir im Unternehmen sind snap und Flatpack verboten.
Wo widerspreche ich mir jetzt?
Ich glaube nicht, das diese Systeme so schnell Einzug halten. So verbreitet sind die FirmenDistributionen(also Distros die von Firmen erstellt werden) nicht.
Immuntable ist ja auch nix Neues gab es schon immer mal wieder und gab es auch schon laenger mit einer Distribution.
Das ist nur wieder mal ein neuer Aufhaenger der Firmendistros.
Flatpack/snap werden im Firmenbereich wohl eher nicht verwendet werden, da in dem Bereich meist Software zentral ausgerollt wird und selbst zu installieren hat da eh keiner was.
Also bei mir ist das so.