Seiten: [1] 
|
 |
|
|
Autor
|
Thema: tmpfs - /tmp auslagern auf das RAM (Gelesen 821 mal)
|
|
heinrich
Jr. Member
 Offline
Einträge: 59
Ich liebe dieses Forum!
|
 |
tmpfs - /tmp auslagern auf das RAM
« am: 02. Februar 2024, 17:36:18 »
|
|
Hallo Suletuxe, nach langer Zeit, auch "Dank" Corona, melde ich mich mal wieder.
In gewisser Weise bin ich euch Untreu geworden und verwende auf Debian basierende Distris. Nachdem ich MX-Linux neu aufgesetzt habe, ist mir wahrscheinlich ein Fehler unterlaufen. Da ich eine SSD in meinem PC habe, wollte ich die Zugriffe auf dieselbe verringern, um deren Lebensdauer zu verlängern. Dies wird empfohlen, ob es aber für den PC-Hausgebrauch nötig ist, weiss ich nicht.
Ich habe also gemäß Anweisung in https://wiki.ubuntuusers.de/SSD/Auslagerung/ das Verzeichnis /tmp mit dem Standardbefehl in das RAM verlagert, sodaß vom RAM bis zu 50 % für /tmp abgezwackt werden können. Mein RAM ist 8 GB groß, also dürfen bis zu 4 GB für die Auslagerung verwandt werden. Kurz danach wurde ich in dem Artikel auf die "Notwendigkeit"? einer RAM-Disk hingewiesen. Also habe ich auch diese gemäß Methode 1 in https://wiki.ubuntuusers.de/RAM-Disk_erstellen/ erstellt.
Nun ergab die Kontrollabfrage mit "df -h" allerdings, daß sowohl für den ausgelagerten Ordner /tmp aus meiner 1. Aktion als auch durch meine 2. Aktion jeweils(?) 4 GB als Größe angegeben wurden. Durch die 2. Aktion können standardmäßig /run, /run/lock, /dev/shm, /run/user/112 und /run/user/1000 mit insgesamt 4 GB in das RAM ausgelagert werden.
Meine Frage an euch lautet nun:
Wird das RAM nun durch diese beiden Aktionen addiert bis zu 100 % durch die veranlassten Auslagerungen in Anspruch genommen, oder ist die 1. Aktion nunmehr Bestandteil der 2. Aktion, sodaß insgesamt tatsächlich nur bis zu 4 GB für Auslagerungen zur Verfügung stehen? Falls letzteres zutrifft, dürfte es dann nicht im Extremfall zu Problemen kommen?
Müßte man deshalb dann nicht die Auslagerungen durch Größenänderungen für /tmp und evtl. /dev/shm soweit verringern, sodaß insgesamt für alle 6 Auslagerungen 4 GB nicht überschritten werden können?
Oder ist tatsächlich die Auslagerung von /tmp in der 2. Aktion aufgegangen, was dann wiederum dazu führen müßte, daß ich die Größen für /tmp und evtl. für /dev/shm anpassen müßte, welches dann aber nicht zu meinem ursprünglich anvisierten Vorhaben führt, nur /tmp in das RAM zu verlagern und zwar mit 4 GB.
Ich habe versucht, die 2. Aktion rückgängig zu machen durch Löschen des Ordners /media/ramdisk, durch Löschen des tmpfs-Befehls in der fstab und umount der eingehängten Verzeichnisse. Letzteres wurde logischerweise abgewiesen, weil die Verzeichnisse busy (sie enthielten Daten) waren. Trotz Auskommentierung/Löschung des tmpfs-Befehls und PC-Neustart hat sich das Ergebnis der "df -h" - Abfrage nicht verändert. Die mit der 2. Aktion einghängten 5 Verzeichnisse sind immer noch eingehängt und somit wohl immer noch aktiv.
Zu meinem hausgemachten Problem habe ich im Internet keine Antworten gefunden. Scheinbar bin ich der einzige mit solch einem Problem. Vielleicht kann einer von euch Experten mir helfen? Ich bin nicht mehr so im Thema, weil die Computerei für mich nicht mehr so wichtig ist.
Zur Veranschaulichung habe ich tmpfs nach Löschung des Mount-Befehls in der fstab mit dem Befehl "df -ah | grep tmpfs" abgefragt und nachstehendes Ergebnis erhalten (sh. png-Dateien tmpfs-Abfrage und fstab).
tmpfs für /tmp habe ich hier versuchsweise auf 2 GB gesetzt.
Die Ausgabe "df: /run/user/1000doc: Die Operation ist nicht erlaubt" kann ich nicht einordnen. Z. Zt. habe ich nur kWrite, die Bash, Firetools und Firefox in Firejail geöffnet.
Warum Firejail als Einhängepunkt für tmpfs hier auftaucht, ist mir ebenfalls unklar.
Ich wäre dankbar, wenn mir jemand helfen könnte, denn das RAM gehört nunmal zu den wichtigsten Bestandteilen eines PC. Alternativ bliebe mir wohl nur die Wahl, das System neu aufzusetzen.
Heinrich
|
|
|
|
Andreas
Administrator
Offline
Einträge: 1144
Linux von Innen
|
|
Re:tmpfs - /tmp auslagern auf das RAM
« Antwort #1 am: 02. Februar 2024, 18:15:11 »
|
|
Hallo Heinrich,
hast Du auch das "normale" (in deiner fstab ausdokumentierte) tmpfs wieder aktiviert? Ich muss gestehen, dass ich auf die Idee das tmp-Verzeichnis in den RAM zu verlagern in meinem Leben noch nicht gekommen bin - ja, mir sträuben sich bei dem Gedanken sogar die Haare. Ins tmp-Verzeichnis kommen auch etliche User-temp-Daten, und die können locker 4GB überschreiten. Die Idee ist (wie Du selbst siehst) kontraproduktiv.
Wenn die Verzeichnisse auch mit komplett "originaler" fstab gemounted bleiben (nach Neustart) und Du weiter nichts geändert hast, kann es höchstens sein, dass die Sachen in der initramfs gespeichert sind. Da ich Debin-Distros vor 5 Jahren verlassen habe weiß ich den Befehl zum Neubau der initramfs nicht mehr aus dem Kopf - aber eine Internetrecherche wird Dir sicher helfen.
Du müsstest aber dazu von einem USB-Stick ein "sauberes" System booten und dann in dein MX-Linux chrooten. Aus dieser Umgebung heraus baust Du dann dein Initramfs neu. Ist ein lohnender Ansatz denke ich.
Ich nutze auf meinen Servern teilweise seit 8 Jahren SDDs - die laufen 24/7 seitdem ohne Probleme. Ich denke folglich dein Vorsorgegedanke war sinnfrei...
LG
Andreas
|
|
 Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 383
|
|
Re:tmpfs - /tmp auslagern auf das RAM
« Antwort #2 am: 02. Februar 2024, 19:02:20 »
|
|
Hallo Heinrich,
Mit der Idee das /tmp Verzeichnis ins RAM zu verschieben bist du nicht alleine. Ich selbst hatte auch schon die Idee gehabt, um meine SSD zu schonen, dann habe ich aber festgestellt, dass dies schon von Arch umgesetzt wird.
❯ findmnt --types tmpfs
TARGET SOURCE
FSTYPE OPTIONS
/tmp tmpfs tmpfs rw,nosuid,nodev,size=4022980k,nr_inodes=1048576,inode64
/dev/shm tmpfs tmpfs rw,nosuid,nodev,inode64
/run tmpfs tmpfs rw,nosuid,nodev,size=1609192k,nr_inodes=819200,mode=755,inode64
└─/run/user/1000 tmpfs tmpfs rw,nosuid,nodev,relatime,size=804592k,nr_inodes=201148,mode=700,uid=1000,gid=1000,inode64
|
|
Jetzt aber zu dem was ein wenig Licht ins Dunkel bringen wird:
Ein tmpfs Dateisystem ist kein reines virtuelles RAM Dateisystem. tmpfs Nutz bevorzugt den RAM kann aber auch wenn dieser nicht mehr ausreichen sollte, den swap mitbenutzten. Bedeutet das, wenn dein tmpfs volllaufen sollte, dann auf deine Swappartition ausgelagert wird.
Mit anderen Worten du kannst so viele tmpfs Dateisysteme mit unterschiedlichen größen anlegen wie du möchtest, laufen diese voll wird geswapt.
Dieses Verhalten empfinde ich als optimal, zumal soll der swap schließlich als Backup dienen, falls der RAM mal zur Neige geht. Aber dies auch nur im Notfall.
Edit:
Was Andreas meinte das sich eine noch nicht korrigierte /etc/fstab im initramfs befinden kann stimmt. Deswegen solltest du das sicherhaltshalber mal neu generieren.
Unter Linux Mint musste ich das damals mit dem tool mkinitramfs machen. Das ging aber auch genauso wie bei Arch aus dem laufenden Betrieb
Edit 2:
Warum df ein fehler bei /run/user/1000/doc ausspuckt. Sagt die Brave Search AI folgendes dazu:
df /run/user/1000/doc
The issue you’re encountering with the df command and the /run/user/1000/doc directory is a known problem in various Linux distributions, including Ubuntu, Fedora, and Manjaro. The error message, “Operation not permitted,” is due to the immutable bit being set on these directories.
To help you understand the situation, let’s break down the problem and the possible solutions step-by-step:
Understanding the problem: The immutable bit is a file attribute that prevents a file from being modified, deleted, or renamed. In this case, the immutable bit is set on the /run/user/1000/doc directory, causing the df command to fail with the “Operation not permitted” error.
Checking if the immutable bit is set: To verify if the immutable bit is set, you can use the lsattr command. Run the following command as the root user:
lsattr -d /run/user/1000/doc
If the output contains the i character, it means the immutable bit is set.
Clearing the immutable bit: To resolve the issue, you can clear the immutable bit using the chattr command. Run the following command as the root user:
chattr -i /run/user/1000/doc
After running this command, the df command should work without the “Operation not permitted” error.
However, it’s essential to understand that clearing the immutable bit might not be a permanent solution, as some applications or services might set the immutable bit again. In such cases, you may need to identify the application or service causing the issue and configure it accordingly.
In some cases, the issue might be related to specific versions of the df command or the Linux kernel. Updating your system to the latest version might help resolve the issue.
Lastly, it’s worth noting that the /run/user/1000/doc directory is related to the XDG Desktop Portal, which provides a secure and integrated mechanism for applications to interact with the system. If you’re experiencing this issue, it might be a good idea to check if there are any known bugs or issues related to the XDG Desktop Portal in your specific Linux distribution.
|
|
Also der Fehler wäre in XDG Desktop Portal zu suchen. Wenn es einen stören sollte, ansonsten kann man das wohl ignorieren.
|
| « Letzte Änderung: 03. Februar 2024, 09:48:48 von Sebastian » |
Gespeichert
|
|
|
|
Andreas
Administrator
Offline
Einträge: 1144
Linux von Innen
|
|
Re:tmpfs - /tmp auslagern auf das RAM
« Antwort #3 am: 03. Februar 2024, 07:39:54 »
|
|
Hallo Sebastian,
das mit dem "initramfs aus dem laufenden Betrieb bauen" möchte ich nochmal vertiefen, denn es kann zu Fehlern führen wenn man glaubt, man baut eine "default-initramfs" wenn man das tut. Da habe ich schon leidvolle Erfahrungen mit gemacht wenn ich von einem RAID1 boote, und die Devices bei boot anders heißen als später im Betrieb. Dann baut man ein initramfs das ein falsches Device enthält.
Wenn Du gebootet hast und Du hast deine tmpfs-mounts aktiv und baust dann ein initramfs, dann gehen genau diese Einstellungen auch ins initramfs ein. Sollte es Dir also nicht gelingen, das alles vor dem Bau zu deaktivieren, dann befindest Du Dich in einer Endlosschleife. In dem Fall chrootest Du mit einem "sauberen boot" in dein System und baust dann - dann baust Du eine wirklich saubere initramfs bei der nicht während des bootend aufgetretene unerwünschte Effekte mit drin sind.
Man sollte auch die Logik hinter tmpfs beachten. Es ist sinnfrei, Plattenaktivität für /tmp zu reduzieren und im gleichen Zuge Plattenaktivität für /swap zu erhöhen. Die liegt ja auch auf der SSD.
@Heinrich:
Wie Sebastian schon sagte: bei Arch-basierten Distris ist schon vieles von dem was Du andenkst automatisch drin. Kommt bei Debian vielleicht auch in ein paar Monaten - oder Jahren...
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 383
|
|
Re:tmpfs - /tmp auslagern auf das RAM
« Antwort #4 am: 03. Februar 2024, 09:33:45 »
|
|
das mit dem "initramfs aus dem laufenden Betrieb bauen" möchte ich nochmal vertiefen, denn es kann zu Fehlern führen wenn man glaubt, man baut eine "default-initramfs" wenn man das tut. Da habe ich schon leidvolle Erfahrungen mit gemacht wenn ich von einem RAID1 boote, und die Devices bei boot anders heißen als später im Betrieb. Dann baut man ein initramfs das ein falsches Device enthält.
|
|
Deswegen sollte man am besten nur mit UUIDs arbeiten statt mit Device Namen.
Wenn Du gebootet hast und Du hast deine tmpfs-mounts aktiv und baust dann ein initramfs, dann gehen genau diese Einstellungen auch ins initramfs ein. Sollte es Dir also nicht gelingen, das alles vor dem Bau zu deaktivieren, dann befindest Du Dich in einer Endlosschleife. In dem Fall chrootest Du mit einem "sauberen boot" in dein System und baust dann - dann baust Du eine wirklich saubere initramfs bei der nicht während des bootend aufgetretene unerwünschte Effekte mit drin sind.
|
|
Das war mir noch nicht aufgefallen. Da muss ich mich noch mal drüber schlau machen.
Man sollte auch die Logik hinter tmpfs beachten. Es ist sinnfrei, Plattenaktivität für /tmp zu reduzieren und im gleichen Zuge Plattenaktivität für /swap zu erhöhen. Die liegt ja auch auf der SSD.
|
|
Das ist richtig. So wie es bei Arch voreingestellt ist finde ich es aber Optimal, so das erst immer der RAM verwendet wird und im Notfall auf dem Swap ausgewichen wird.
Im Kernel Handbuch habe ich noch gelesen, das es für ein tmpfs die mount Option noswap gibt. Somit kann man das auslagern in den Swap verhindern und es wird nur der RAM verwendet. Aber wie gesagt da der swap als Backup zu sehen ist, sollte man schon einen guten grund haben das zu deaktivieren.
|
|
Gespeichert
|
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 383
|
|
Re:tmpfs - /tmp auslagern auf das RAM
« Antwort #5 am: 03. Februar 2024, 10:20:58 »
|
|
@heinrich
Bezüglich deiner Aussage:
Warum Firejail als Einhängepunkt für tmpfs hier auftaucht, ist mir ebenfalls unklar.
|
|
Das erklärt sich höchstwahrscheinlich, wenn man nachforscht wofür das /run verzeichnis überhaupt gut ist, bzw. wofür dies verwendet wird.
Laut dem Filesystem Hierarchy Standard (FHS) steht dazu folgendes drin:
This directory contains system information data describing the system since it was booted. Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process.
The purposes of this directory were once served by /var/run. In general, programs may continue to use /var/run to fulfill the requirements set out for /run for the purposes of backwards compatibility. Programs which have migrated to use /run should cease their usage of /var/run, except as noted in the section on /var/run.
Programs may have a subdirectory of /run; this is encouraged for programs that use more than one run-time file. Users may also have a subdirectory of /run, although care must be taken to appropriately limit access rights to prevent unauthorized use of /run itself and other subdirectories.
|
|
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html
Mit anderen Worten, Programme können dort Unterverzeichnisse anlegen die mehr als eine Datei wärend ihrer Laufzeit benötigen um ihre Arbeit zu vollrichten aber nicht in das /tmp verzeichnis landen sollen weil diese nicht versendlich gelöscht werden sollen. Das ist also konkrett vom Programm abhähig und wird da wohl von Firejailselbst angelegt worden sein. Da Firejail wohl was mit Sandbox zu tun hat ist das auch sehr warscheinlich. Wenn man also noch mehr und genauers erfahren möchte wiso weshalb müsste man sich jetzt noch weiter mit Firejail beschäftigen.
Bzw. falls Firejail bestandteil deiner Distribution sein sollte, könnte es auch eine bewusste Entscheidung der Distribution für irgendetwas sein, die firejail anders konfiguriert haben. Dann kann man vielleicht in der Dokumentation seiner Distribution auch etwas darüber finden.
LG
Sebastian
|
| « Letzte Änderung: 03. Februar 2024, 10:28:42 von Sebastian » |
Gespeichert
|
|
|
|
heinrich
Jr. Member
Offline
Einträge: 59
Ich liebe dieses Forum!
|
|
Re:tmpfs - /tmp auslagern auf das RAM
« Antwort #6 am: 03. Februar 2024, 10:35:22 »
|
|
Hallo Andreas und Sebastian,
danke für eure schnellen Antworten.
/tmp ins RAM verlagert habe ich schon bei Vorgänger-Distris mit meiner 1. Aktion und damit keine Probleme gehabt.
Mein wohl eigenes Problem ist erst mit meiner 2. Aktion entstanden, weil mir nicht klar war und immer noch ist, was ich damit angerichtet habe. Wenn ich Sebastians Ausführungen folge, kann man wohl mit tmpfs soviele Verzeichnisse ins RAM verlagern wie man will (begrenzt natürlich durch die RAM- und Swap-Größe) und sie sind unabhängig voneinander. Weil tmpfs Bestandteil des Kernels ist(?), werde ich meine 2. Aktion nicht rückgängig machen, sondern nur die Werte verändern/verringern können. Folgen davon - keine Ahnung.
MX-Linux ist noch nicht vollständig konfiguriert und deshalb werde ich die Distri wieder neu installieren, um ein sauberes System zu bekommen. Alle anderen Experimente verschlingen nur unnütz Zeit mit für mich vollkommen unabsehbaren Folgen.
Der Gedanke meiner Aktion war, die Schreibvorgänge auf die SSD zu verringern um die Lebensdauer der SSD zu erhöhen. Doch wenn ich von Dir, Andreas, lese, dass deine SSDs seit 8 Jahren im Dauerbetrieb ohne Probleme laufen, dürfte meine Vorsorge für meinen Hausgebrauch überflüssig sein. Vielleicht hängt die problemlose Nutzung aber damit zusammenen, dass Arch lt. Sebastian schon eine entsprechende Vorsorge implementiert hat?
Wie dem auch sei, ich werde MX-Linux in der neuesten Version installieren.
Gründe für MX-Linux:
Es läuft sehr stabil.
Es hat ein sehr ausführliches deutsches Benutzerhandbuch.
Es hat eine Menge MX-Werkzeuge an Bord, die den Umgang mit dem System sehr erleichtern. Man muß nicht immer die Bash verwenden, was leider letztlich allerdings dazu führt, dass viele erarbeitete Linux-Kenntnisse in Vergessenheit geraten.
Vielleicht, wenn ich mehr Zeit abzwacken kann/will, beschäftige ich mich wieder mit Arch in Form von Manjaro (was mir vor Jahren sehr gefallen hat aber sehr zeitaufwendig war, weil meine Englischkenntnisse noch aus der Schulzeit stammen) oder eben mit EndeavourOS.
Ich danke euch nochmals und wünsche euch ein schönes Wochenende
Heinrich
P.S. @Sebastian
Firejail ist eine Sandbox und wurde von mir installiert für Firefox etc. und Thunderbird.
Der Gedanke, dass Firejail selbst den Mountpunkt im RAM angelegt hat, ist mir auch schon gekommen. Daraus folgt aber, wieviele andere Programme nutzen denn noch RAM zum Auslagern mittels tmpfs? Das wird ja immer unübersichtlicher.
|
|
Gespeichert
|
|
|
|
Andreas
Administrator
Offline
Einträge: 1144
Linux von Innen
|
|
Re:tmpfs - /tmp auslagern auf das RAM
« Antwort #7 am: 03. Februar 2024, 12:14:23 »
|
|
Hallo Heinrich,
bis vor 4 Jahren liefen meine Server auch unter Debian. Ich bin es dann allerdings Leid gewesen, dass ich alle 2 Jahre ein "durchgemachtes Wochenende" brauchte (wenn es einen Versionssprung gegeben hat) um nach einem Versionsupgrade wieder alles so lauffähig zu haben wie vorher - das hat seit dem Umstieg auf Arch ein Ende. Es sind also 4 Jahre Betrieb der SSDs unter Debian und 4 unter Arch. Sollte für den Hausgebrauch kein Problem sein.
Manjaro:
Meine intensive Warnung davor! Manjaro schaltet (völlig sinnfrei) eine weitere "Testphase" vor die normalen Repos, wodurch Pakete dort gegenüber Arch verzögert erscheinen. Das macht diese Distri zu einer Insel: Arch-Pakete sind nur bedingt verwendbar, und selbst AUR-Pakete bauen nicht immer, weil sie auf den neuesten Arch-Paketen basieren. Also lieber gleich Arch (und wenn Du mehr Klicki-Bunti-Untersützung für die Installation willst EndeavourOS).
LG
Andreas
|
| « Letzte Änderung: 03. Februar 2024, 12:15:46 von Andreas » |
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 383
|
|
Re:tmpfs - /tmp auslagern auf das RAM
« Antwort #8 am: 03. Februar 2024, 18:38:04 »
|
|
@Heinrich
Der Gedanke, dass Firejail selbst den Mountpunkt im RAM angelegt hat, ist mir auch schon gekommen. Daraus folgt aber, wieviele andere Programme nutzen denn noch RAM zum Auslagern mittels tmpfs? Das wird ja immer unübersichtlicher.
|
|
Das kann man natürlich generell nicht beantworten. Aber bei einem Programm wie firejail macht das ja auch Sinn.
Es hat eine Menge MX-Werkzeuge an Bord, die den Umgang mit dem System sehr erleichtern. Man muß nicht immer die Bash verwenden, was leider letztlich allerdings dazu führt, dass viele erarbeitete Linux-Kenntnisse in Vergessenheit geraten.
|
|
Dasselbe gilt auch für EndeavourOS, das ist im Grunde ein Arch mit einem zusätzlichen Repository mit ein paar Hilfe Tools und einem grafischen Installer.
Da wäre z.B. das Skript eos-update, das man verwenden kann, um sein Betriebssystem upzudaten. Dies fängt dabei viele Anfängerfehler ab. Wie z.B. das Aktualisieren des arch-keyrings etc.
Oder das Skript eos-pacdiff, das nach .pacnew Dateien sucht und einem beim Mergen der neuen Config Dateien mithilfe von meld hilft. Dies ist bei einem Arch Linux etwas wichtiger, dass neue Einstellungen in den Config Dateien übernommen werden. Da man schließlich die neuste Version seiner Programme verwendet. Bei Debian Systeme muss man da nicht so darauf achten, weil diese sich immer erst "meistens" zu einer neuen Hauptversion verändern. Und dadurch ist das mergen bzw. Anpassen von Konfigurationsdateien nach einem Update vielen fremd.
Ansonsten würde ich von Manjaro auch abraten. Da diese zusätzliche Verzögerung von Updates, wie Andreas schon sagte, mehr Probleme als nutzten, bringt. Dann sollte man doch lieber bei einer richtigen LTS Distribution bleiben, wenn man nicht das neuste bekommen möchte.
Und was die Langlebigkeit von SSDs anbelangt, da muss man heutzutage wirklich nicht mehr so viel Aufwand betreiben für den Hausgebrauch.
Da musste nur mal schauen, was die Platten von heute so als Terabytes writen (TBW) stehen haben, da liegen als Beispiel genommen viele SATA Platten bei über 100 TB also bis die kaputt geschrieben sind, wird es wohl als Privatperson lange dauern. Solange man nicht übertreibt und jeden Tag mit mehren Gigabytes darauf herumschreibt. Hat man mit solchen Datenmengen regelmäßig zu tun, wird man wahrscheinlich auch ein RAM Problem wohl haben, wenn das alles in den Arbeitsspeicher verschoben wird. Und der Kleinkram wiederum lohnt der Aufwand nicht.
PS:
Schön das du dich hier im Forum mal wieder gemeldet hast. Ich höre gerne auch mal was von anderen Distributionen, damit man vergleichen kann. 
|
| « Letzte Änderung: 03. Februar 2024, 18:45:01 von Sebastian » |
Gespeichert
|
|
|
|
Seiten: [1] 
|
|
|
|
|
|
|
