SSD: Mython und Realität

[buhtz]

@Moderator: Bitte in passende Untergruppe verschieben, falls das hier doch nicht passend ist.

Aus gegebenen Anlass (Forum-Beitrag "System durch Festplatte zu langsam?") mache ich mir Gedanken darum, Debian unstable auf einer SSD aufzusetzen. Dazu fiel mir der Blog-Beitrag "Linux und moderne SSD-Speicher" von Helmut Karger vom März 2016 auf. Hauptsächlich geht es bei seinen Punkten darum, Schreibzugriffe auf die SSD zu minimieren.
Am Ende seines Beitrags relativiert er die gesamten Tips auch dahingehend, dass diese bei der mitlerweile ausgereiften SSD-Technik für den Hausgebraucht nicht unbedingt notwendig seien. Ebenso merkt er an, dass einige der Punkte "veraltet" seien. Aber so ganz geht er nicht darauf ein - hab ihn daher zu diesem Thread eingeladen.

Wegen des Alters des Beitrags, möchte ich an dieser Stelle gerne einige der Punkte nochmal aufgreifen und die Frage in den Raum stellen, ob das heute noch gilt bzw. sinnvoll ist, oder ob sich Linux (Debian unstable!) in diesem Bereich schon weiterentwickelt hat. Sind einige der Tips dort also obsolet geworden? Bitte ggf. um Einwände und Korrektur.

Unter "4) Richtiges Alignment einstellen" geht es, um das Ausrichten der Partitionen an den Blockgrenzen der SSD. Herr Karger merkt an, dass OpenSuse und Ubuntu dies bereits von Haus aus richtig machen. Daher gehe ich mal davon aus, dass Debian unstable dies auch tut?
Verstehe ich es ebenso richtig, dass man die Ausrichtung selbst vornehmen muss, wenn man selbst manuell Partitioniert?

5) Geeignetes Dateisystem verwenden
Ext4 wird hier empfohlen und von BTRFS abgeraten. Einwände?
Da fällt mir ein, ich hatte auch mal irgendwo gelesen, man sollte das ext4-journal ausschalten, um die SSD zu schonen. Humbug?

6) Keine Swap-Partition auf SSD
Wenn man nur eine SSD hat, stirbt auch keiner von, oder? Wer sich sein gesamtes System auf SSD leisten kann, hat auch ausreichend RAM im Gerät, so das swapping gar nicht mehr vorkommt. Der Swap ist dann nur noch für hibernate (aka resume-to-disk, aka S3) sinnvoll.

7) /tmp in Ramdisk verlagern
Interessante Idee. Dabei denke ich mir immer: Wenn das so sinnvoll und effektiv wäre, würde es doch die Distro von selbst so anlegen. Ist es sinnvoll? Warum bietet Debian unstable das bei der Installation dann nicht ggf. an - was ich ehrlich gesagt, noch gar nicht ausprobieren konnte?

Read-Access-Time-Stamp abschalten
Klingt auch sinnvoll.

9) TRIM aktivieren
Hier würde es mich wundern, wenn Debian das nicht schon von Haus aus irgendwie macht?

10) I/O-Scheduler auf ‚deadline‘ setzen
Scheduler wechseln. Auch hier würde ich erwarten, dass Debian bei der Installation von Haus aus einen sinnvollen Scheduler wählt oder anbietet?

11) Hibernation abschalten
Eine von mir häufig genutzte Funktion. Warum sollte ich das Abschalten? Hibernation passiert ja nun auch nicht so häufig, dass man es als SSD-Lebenszeitmindernden Schreibvorgang bezeichnen könnte.

12) Browser Cache deaktivieren
Erstens würde ich gerade den Firefox Cache wegen Geschwindigkeitsvorteilen auf der SSD lassen. Zweitens würde ich von Firefox erwarten, dass es hier eine SSD erkennt und irgendwelche intelligenten Lösungen parat hat. Den Cache vollständig zu deaktivieren würde vermutlich das System auch verlangsamen.

Noch eine Bonus-Frage:
Wie stirbt eigentlich eine SSD?
Ich meine eine HDD kann sehr plötzlich und überraschend abrauchen - u. a. wegen mechanischer Teile.
Wie ist es bei einer SSD? Die Zellen gehen mit der Zeit zu Neige - eine nach der anderen. Aber das macht keinen plötzlichen Ausfall, sondern einen sehr langsamen. Man wäre also darauf vorbereitet, dass die Platte hobs geht?

[DeletedUserReAsG]

7) /tmp in Ramdisk verlagern
Interessante Idee. Dabei denke ich mir immer: Wenn das so sinnvoll und effektiv wäre, würde es doch die Distro von selbst so anlegen.

Wird doch genau so angelegt (in einem tmpfs).

Ansonsten: SSDs gelten mittlerweile als ausreichend haltbar, um sich nicht weiter drum kümmern zu müssen. Man sollte halt nicht das billigste Modell wählen, das im Mediamarkt in der Grabbelkiste liegt: bei diesem lautet die Antwort auf deine Bonusfrage, dass es von einer Sekunde auf die andere nicht mehr zugreifbar war, und dabei so warm wurde, dass es nach überhitzter Elektronik stank. Ansonsten sollte™ es so sein, dass man am Status des Wear-Leveling-Feldes in SMART-Ausgabe sieht, wann die angedachte Verschleißgrenze erreicht ist. Dazu mal ein Auszug von einem Samsung 840, das mittlerweile mehrere Jahre in meinem täglich genutzten T400 verbracht hat:

Code: Alles auswählen

  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       31482
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       831
177 Wear_Leveling_Count     0x0013   096   096   000    Pre-fail  Always       -       40

Man sieht: bei einer reinen Laufzeit von ~3½ Jahren wird ein Verschleiß von 4% verzeichnet. Ohne, dass ich da irgendwelche Optionen zum Schonen des SSDs gesetzt hätte.

[buhtz]

7) /tmp in Ramdisk verlagern
Interessante Idee. Dabei denke ich mir immer: Wenn das so sinnvoll und effektiv wäre, würde es doch die Distro von selbst so anlegen.

Wird doch genau so angelegt (in einem tmpfs).

Du meinst, wenn man eine SSD hat wird das automatisch so gemacht?

Hier mit meiner HDD erkenne ich das nicht.

Code: Alles auswählen

$ df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev            3,8G       0  3,8G    0% /dev
tmpfs           781M    3,3M  778M    1% /run
/dev/sda1       1,8T    856G  878G   50% /
tmpfs           3,9G     57M  3,8G    2% /dev/shm
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
tmpfs           3,9G       0  3,9G    0% /sys/fs/cgroup
tmpfs           781M     28K  781M    1% /run/user/1000

[DeletedUserReAsG]

Du meinst, wenn man eine SSD hat wird das automatisch so gemacht?

Ich meinte, dass es heutzutage generell in ein tmpfs gelegt würde. Muss mich da aber korrigieren: auf meinen Debian-Systemen ist’s tatsächlich nicht der Fall, nur auf meinen lokalen Arbeitssystemen (kein Debian).

[Lord_Carlos]

4) Alignment
Sollte Mittlerweile kein problem sein.
Ich habe noch diesen Schnippet hier rumliegen:
sudo parted /dev/sdX
mklabel gpt
mkpart primary 2048s 100%
align-check optimal 1

6)SWAP
Generell scheiden sich bei swap die Geister. Hat aber nichts mit der SSD zu tun.
Wenn du swap brauchst schallte es an.

7) /tmp
Debian hat oft auch defaults die ein paar Jahre hinterhaer haengen.
Das mit /tmp in tmpfs mache ich auch immer, kann aber auch gut sein das es mitlerweile man Standart geworden ist.
Wenn nicht ist das in einer config ein Einzeiler.

10) Hibernation
Ich verstehe die Empfehlung auch nicht.

12) Firefox erkennt da nichts. Und ich wuerde vermuten das der Taeglich ein paar GB drauf schreibt. Aber macht ja nichts.

Wenn nach und nach die Zellen Kaputt gehen ist das ein guter Abgang, denn das kann man auslesen und man sieht wie die SSD die reserve bloecke benutzt.
Bloed ist wenn von einem Tag zum naechsten der Controller kaputt geht.

Noch mehr details gibt es hier: https://wiki.debian.org/SSDOptimization

[geier22]

Durch deinen vorigen Thread angeregt, hab ich mir gerade eine neue Platte zugelegt , da die SAMSUNG_HD753LJ mit der Zeit zu klein wurde und ja auch schon fast 10 Jahre auf dem Buckel hat.
Meine Wahl :
Seagate FireCuda SSHD ST2000DX002 2TB 85,90
Hatte noch nie eine Hybrid- Festplatte,und bin gespannt,wie die sich macht.

Wenn du das System so aufsetzten willst, wie du geschrieben hast(nur ein System). sind 240 GB pure Verschwendung. Ich habe zwei SSD's
und hab die so rein gesteckt und formatiert wie sie waren, ohne groß was zu konfigurieren. Die Datenverzeichnisse sind auf einer relativ schnellen Festplatte ( WDC_WD5000HHTZ)per Symlink verlinkt (inkl. ~/.mozilla und ~/thunderbird und gut ist. Das /home/ bleibt aus der SSD. Gesichert wird das /home/ und die Datenverzeichnisse., die Systempartition nicht. Wenn die SSD verreckt - nicht weiter schlimm.
Neu aufgesetzt, und gut.
Wenn du genug Arbeitsspeiche hast, braucht es keinen Swap, wenn du nicht unbedingt Suspend to Disk brauchen willst. Ich benutze tagsüber den Bereitschaftsmodus (suspend to RAM) Abends wird halt abgeschaltet. Aus dem Bereitschaftsmodus ist der Rechner sofort da. Beim Hibernate spare ich wenige Sekunden. Die habe ich dann auch noch.

[NAB]

Ich hielt diese ganzen "Oh, die arme teure SSD bloß nicht zuviel beschreiben"-Hinweise schon immer für etwas abstrus. Wer so denkt, sollte sich keine oder ne billigere SSD kaufen. Entweder kauft man sie, um sie zu benutzen, oder man sollte sie im Regal liegen lassen ... am besten im Regal vom Händler.

Swap auf SSD ist ne feine Sache, da wird Swap fast wieder etwas benutzbar. Wenn du STD machen willst, bleibt dir eh nichts anderes übrig.

Mit "Alignment" hatte ich seit Jahren keine Probleme mehr. Ich partitioniere immer mit Gparted vor.

Dabei lasse ich immer 10% der SSD frei, in der Hoffnung, dass die SSD dann auch bei eifrigem Gebrauch noch genug frische Sektoren für's Wear Leveling findet ... ob das wirklich was bringt, kann ich nicht sagen.

SSDs sterben schnell und ohne Vorwarnung. Habe Backups!

Was sehr gut funktioniert: Ein Raid1 aus SDD und HDD. Man kann mdadm sagen, dass es nur von der SSD lesen soll. Beim System/Programm-Start hast du also die vollen Vorteile einer SSD. Nur beim Schreiben reißt die HDD die Geschwindigkeit runter.

64 GB reichen locker für ne satte Systeminstallation ohne /home. Da gibt's nur leider kaum was. 128 GB kriegst du inzwischen für 40 Euro.

[Lord_Carlos]

Wenn man lvm benutzt kann man auch eine SSD als cache fuer HDDs benutzten. Im laufenden betrieb mit wenigen Befehlen.

[BenutzerGa4gooPh]

Unter "4) Richtiges Alignment einstellen" geht es, um das Ausrichten der Partitionen an den Blockgrenzen der SSD. Herr Karger merkt an, dass OpenSuse und Ubuntu dies bereits von Haus aus richtig machen. Daher gehe ich mal davon aus, dass Debian unstable dies auch tut?
Verstehe ich es ebenso richtig, dass man die Ausrichtung selbst vornehmen muss, wenn man selbst manuell Partitioniert?

gparted machte (macht?) das empfohlene Alignment nur dann, wenn Partitionstabelle GPT. Eigene Erfahrung.
Empfohlen: https://www.thomas-krenn.com/de/wiki/Pa ... _Alignment

Zur Haltbarkeit: Die meisten Desktop-SSDs dürfen pro Tag mit 40 GB beschrieben werden. Dafür geben manche Hersteller 5 Jahre Garantie:
Sind etwa 70 TB written (TBW). Mit smartmontools kann man das m. E. individuell ermitteln und hochrechnen - und erstaunt sein, wie wenig man schreibt. Einige ältere MLC- und 2D-TLC-SSDs und neueste 3D-TLC-SSD schaffen lt. Herstellerangaben viel mehr als 70 TBW. Kannst ja mal geizhals.de dafür bemühen.

Tja die Notwendigkeit von Trim: Marken-Hersteller unterstützen das laut Datenblatt. Sagt mir viel.

Dabei lasse ich immer 10% der SSD frei, in der Hoffnung, dass die SSD dann auch bei eifrigem Gebrauch noch genug frische Sektoren für's Wear Leveling findet ... ob das wirklich was bringt, kann ich nicht sagen.

Ich habe mit LVM 20% freigelassen. Platz für Snapshots/Merging und online-Backup. Spätestens damit bringt's was. So die Snapshots nicht übergelaufen sind.

[Radfahrer]

Leute,
benutzt eure SSDs wie norme HDDs und gut is.

Alignment macht der Debian-Installer doch schon seit Jahren richtig.
Swap... wer es haben will, soll es machen... und zwar auf der SSD! Wo könnte man den Geschwindigkeitsvorteil besser nutzen?

Mein SSD (OCZ Vertex 2 mit 60GB, ja, eine von den total miesen Dingern, die ständig kaputt gehen )) läuft seit Ende November 2010 in meinem Hauptrechner. Drauf ist das komplette System, also /, swap und /home, wobei ich /home nur für die .configs benutze. Ich habe damals installiert, dabei als Option discard und noatime gesetzt und mich seitdem nie wieder drum gekümmert.

Habe gerade mal einen Lesetest gemacht und festgestellt, dass sie immer auch noch die gleiche Performance zeigt, wie vor 10 Jahren.

[breakthewall]

Ich hielt diese ganzen "Oh, die arme teure SSD bloß nicht zuviel beschreiben ....

Dabei lasse ich immer 10% der SSD frei, in der Hoffnung, dass die SSD dann auch bei eifrigem Gebrauch noch genug frische Sektoren für's Wear Leveling findet ... ob das wirklich was bringt, kann ich nicht sagen.

Hinsichtlich der Langlebigkeit, sind bspw. die Pro-Modelle von Samsung zu bevorzugen. Sind zwar etwas teurer, aber halten mit MLC-Chips nahezu doppelt solange, und besitzen auch bessere Controller. Die Evo-Modelle die auf den TLC-Chips basieren, sind zwar für eine moderate Nutzung in Ordnung, aber für echte Poweruser nicht geeignet.

Du musst selbst keinen Speicher auf einer SSD freilassen. Denn seit etlichen Jahren, bringt jede moderne SSD einen eigenen Speicherbereich mit, der vom Nutzer nicht adressiert werden kann. Je nach Kapazität der SSD, können das viele GB sein, womit Daten für das Wear-Leveling ausgelagert werden. Das ist zugleich aber auch wieder der große Nachteil, da dort ebenfalls sensible Daten ausgelagert werden können. Ein sicheres Löschen von Daten wird somit unmöglich, weshalb alle SSDs heutzutage von Haus aus verschlüsselt sind. Der jeweilige Schlüssel kann somit gelöscht werden, womit alle Daten unwiederbringlich verloren sind. Beim nächsten Systemstart wird ein neuer Schlüssel generiert, was die SSD in den Auslieferungszustand zurückversetzt. Alternativ kann man natürlich auch dm-crypt/LUKS verwenden ab Installation, womit die SSD niemals Klartextdaten sieht.

[NAB]

Hinsichtlich der Langlebigkeit, sind bspw. die Pro-Modelle von Samsung zu bevorzugen. Sind zwar etwas teurer, aber halten mit MLC-Chips nahezu doppelt solange

Das macht die Sache dann aber gleich nahezu vier mal so teuer. Es gibt keine Samsung Pros mehr mit 128 GB, dazu wollen sie für das "nahezu doppel solange" auch nen deftigen Aufpreis.

Und wenn's doch nicht stimmt, was sie behaupten ... sooo lustig ist ne Garantieabwicklung mit Samsung auch nicht.

[BenutzerGa4gooPh]

Einsatzszenarien für Enterprise-SSDs sollten schon stimmen, sonst rausgeworfenes Geld.
https://www.kingston.com/de/ssd/enterprise
https://www.kingston.com/de/ssd/enterpr ... client_ssd

[catdog2]

Unter "4) Richtiges Alignment einstellen" geht es, um das Ausrichten der Partitionen an den Blockgrenzen der SSD. Herr Karger merkt an, dass OpenSuse und Ubuntu dies bereits von Haus aus richtig machen. Daher gehe ich mal davon aus, dass Debian unstable dies auch tut?
Verstehe ich es ebenso richtig, dass man die Ausrichtung selbst vornehmen muss, wenn man selbst manuell Partitioniert?

Die Tools machen das idr. richtig heutzutage, der Installer sowieso. Wenn man was ganz low leveliges oder veraltetes nimmt muss man nat. aufpassen.

5) Geeignetes Dateisystem verwenden
Ext4 wird hier empfohlen und von BTRFS abgeraten. Einwände?
Da fällt mir ein, ich hatte auch mal irgendwo gelesen, man sollte das ext4-journal ausschalten, um die SSD zu schonen. Humbug?

Ob man BTRFS nehmen will oder nicht hat eher wenig mit SSD oder nicht zu tun. Journal aus schalten, kann man machen, ist dann halt Scheiße.

6) Keine Swap-Partition auf SSD
Wenn man nur eine SSD hat, stirbt auch keiner von, oder? Wer sich sein gesamtes System auf SSD leisten kann, hat auch ausreichend RAM im Gerät, so das swapping gar nicht mehr vorkommt. Der Swap ist dann nur noch für hibernate (aka resume-to-disk, aka S3) sinnvoll.

Evtl die swappiness runter setzen oder ein zram device mit höherer Priorität dazwischen setzen um unnötiges swappen zu vermeiden.

7) /tmp in Ramdisk verlagern
Interessante Idee. Dabei denke ich mir immer: Wenn das so sinnvoll und effektiv wäre, würde es doch die Distro von selbst so anlegen. Ist es sinnvoll? Warum bietet Debian unstable das bei der Installation dann nicht ggf. an - was ich ehrlich gesagt, noch gar nicht ausprobieren konnte?

Debian kann das, mittlerweile ist das evtl. sogar voreingestellt.

Read-Access-Time-Stamp abschalten
Klingt auch sinnvoll.

Die Voreinstellung im kernel ist (mittlerweile) relatime welche das stark reduziert aber im Gegensatz zu noatime die meisten Programme, die das verwenden nicht bricht. Also muss man hier nicht mehr unbedingt eingreifen.

9) TRIM aktivieren
Hier würde es mich wundern, wenn Debian das nicht schon von Haus aus irgendwie macht?

Macht es glaub ich nicht, bin mir grad nicht sicher. Gibt da auch den ungeklärten Streitpunkt ob man das besser das Dateisystem erledigen lässt oder lieber periodisch fstrim aufruft.

10) I/O-Scheduler auf ‚deadline‘ setzen
Scheduler wechseln. Auch hier würde ich erwarten, dass Debian bei der Installation von Haus aus einen sinnvollen Scheduler wählt oder anbietet?

Der Kernel erkennt, dass es sich nicht um eine rotierende Scheibe handelt und passt die Parameter des Schedulers entsprechend an. Hier muss man im allgemeinen Fall nichts mehr ändern.

11) Hibernation abschalten
Eine von mir häufig genutzte Funktion. Warum sollte ich das Abschalten? Hibernation passiert ja nun auch nicht so häufig, dass man es als SSD-Lebenszeitmindernden Schreibvorgang bezeichnen könnte.

Was man machen kann ist vorwiegend suspend to ram zu verwenden. Zumindest Notebooks brauchen in diesem Zustand idr. kaum Strom und es geht auch noch schneller. Ansonsten ja ein nützliches Feature, warum abschalten?

12) Browser Cache deaktivieren
Erstens würde ich gerade den Firefox Cache wegen Geschwindigkeitsvorteilen auf der SSD lassen. Zweitens würde ich von Firefox erwarten, dass es hier eine SSD erkennt und irgendwelche intelligenten Lösungen parat hat. Den Cache vollständig zu deaktivieren würde vermutlich das System auch verlangsamen.

SSD Erkennung macht der glaub ich nicht aber auch die Browser cachen schon mal sehr viel im RAM. Was beim Firefox im Vergleich noch heftiger ist (falls sie das noch nicht gefixt haben) ist dass er ziemlich oft seinen Zustand in einer etwas unsparsamen Art und Weise weg schreibt (damit er alle Tabs wieder herstellen kann nach einem Crash).

Wie stirbt eigentlich eine SSD?
Ich meine eine HDD kann sehr plötzlich und überraschend abrauchen - u. a. wegen mechanischer Teile.
Wie ist es bei einer SSD? Die Zellen gehen mit der Zeit zu Neige - eine nach der anderen. Aber das macht keinen plötzlichen Ausfall, sondern einen sehr langsamen. Man wäre also darauf vorbereitet, dass die Platte hobs geht?

Generell hat man natürlich ohne mechanische Komponenten eine große Fehlerquelle weniger. Wie bei jedem elektronischen Gerät kann natürlich der plötzliche Tod eintreten, das nehmen sich HDD und SSD nix. Genauso haben beide recht komplexe Firmware, die mal fehlerhaft sein kann.

Hier mal ein Beispiel meiner noch nicht ganz 3 Jahre alten Crucial_CT512MX100SSD1 in einem doch relativ stark genutztem Rechner ohne großartige Schreibsparmaßnahmen:

Code: Alles auswählen

202 Percent_Lifetime_Used   P---CK   096   096   000    -    4

Wenn wir jetzt davon ausgehen, dass das Ding keinen keinen Mist erzählt und mal von 5% in 3 Jahren ausgehen hält das Ding bei gleichbleibender Nutzung noch ein paar Jahrzehnte. Wobei ich allerspätestens nach einem Jahrzehnt davon ausgehe, dass das Ding aufgrund der technischem Fortschritts eh überholt ist.