Erschrocken musste ich feststellen, das meine Festplatte im Tablet PC so langsam den Geist aufgibt. Aufgefallen war es beim kopieren einer größeren Datei, die massiv Lesefehler verursachte. Ach ja, am Sonntag früh hatte das booten länger als das Frühstück gedauert... Das ist natürlich kein Zustand, deshalb musste eine SSD (Solid State Disc) her. Wenn mann keine allzu große Speichermengen benötigt, sind sie mittlerweile durchaus erschwinglich.
Ich habe mich für die ADATA S599 entschieden. Die Platte bekommt man mit 64GB für m die 100.- €
Allerdings gibt es bei den SSD so einiges beachten, schließlich sind SSD im Grunde genommen nur Flash Speicher, die sind nun mal nicht für unendlich viele Schreibvorgänge konzipiert.
Da wäre z.B. welches Dateisystem kann und sollte man verwenden, welche Optionen sind sinnvoll. Welche Bereiche gehören nach Möglichkeit nicht auf die SSD? Sollte man die SSD beim Partitionieren ausreizen, oder sollte man einen Bereich unpartioniert lassen? Welche Wear Leveling Technologie verwendet der Plattencontroller innerhalb der SSD?
Ich fange mal von hinten an.
Was ist überhaupt Wear Leveling?
Die geschriebenen Blöcke können in zwei Kategorien eingeteilt werden. zum Einen sind das Dateien, die sich selten oder nie ändern. Zum Beispiel Bilder, Filme oder Dateien vom Betriebssystem. Diese Blöcke, (für den Controller gibt es nur zu schreibene Blöcke, einzelne Bytes existieren in dieser Betrachtung nicht) werden geschrieben und liegen dann ewig im Speicher herum. Der interne Schreibcounter steht für diesen Block also für lange Zeit auf 1. Zum Anderen gibt es die Dateien, die sich häufig ändern, das sind zum Beispiel Textfiles, Logfiles, oder auch Status- Dateien usw. Diese Dateien, - besser die Blöcke, in denen diese Dateien residieren-, werden vom Controller anders behandelt. Wenn sich ein Block zum wiederholten Mal geändert hat, dann schreibt der Controller diesen geänderten Block an einen anderen Platz in der SSD auf einen Platz, der noch nie beschrieben worden ist. Das Ganze merkt sich der SSD-Controller in einer internen Äbersetzungstabelle. Er würde, wenn man explizit diesen Block anfordert, z.B. mit einen dd Kommonado behaupten er liefere den Block von der Stelle, an der er zum allerersten Mal geschrieben worden ist, durch seine Tabelle liefert er natürlich aber den tatsächlichen Block, der physikalisch an einem ganz anderen Ort liegen kann.
Diese Mimik nennt der Hersteller Wear Leveling. Innerhalb dieser Strategie gibt es mehrere Varianten, schließlich haben unterschiedliche Firmen unterschiedliche Strategien. Der Controller sorgt also dadurch dafür, das die Blöcke gleichmäßig beschrieben werden und somit gleichzeitig altern. Jeder Block, der vom Betriebssystem jemals beschrieben wurde, gilt als belegt und der interne Schreibcounter geht um eins hoch.
Wenn man nun aber von vorn herein einen Bereich unpartitioniert gelassen hat, dann ist dieser Blockbereich für diesen Wear Leveling Mechanismus verfügbar und es dauert entsprechend lange, bis der Controller Blöcke benutzt, die bereits mehrfach beschrieben worden. Man verzögert also durch diese Maßnahme, den Zeitpunkt, an denen jeder Block eine gewisse Schreibzyklenanzahl überschritten hat. Die Flashzellen haben nämlich die unangenehme Eigenschaft, mit dem zunehmenden Schreibzyklen immer langsamer zu werden, sie altern.
Das beschreiben eines Blockes vom Betriebssystem hält der SSD Controller zwar fest, er kann jedoch nicht wissen, ob und wann dieser Block wieder freigegeben wurde. Denn die üblichen Filesysteme markieren Dateien, die nicht mehr benötigt werden nur als gelöscht, zwar auf gänzlich verschiedene Arten, aber es wird eben nicht der Block auf der Platte gelöscht.
Nun gibt es den neuen ATA Befehl TRIM. Der wird vom Linux Kernel ab 2.6.33 unterstützt. Bei Debian Kerneln ist auch der Kernel ab 2.6.32.5 gepatchet und kennt fortan den Befehl.E
Wenn jetzt das verwendete Filesystem bei löschen einer Datei das Kommando TRIM zum SD Controller sendet, kann der Controller ggfs. den betroffenen Block als wieder freigegeben markieren und im späteren Verlauf erneut allokieren.
Die Größe des Blockes, der einem Rutsch auf die SSD geschrieben wird ist vom Controller abhängig. Äblich sind 32K, wieviel es nun tatsächlich sind, steht nicht im Datenblatt und kann nur mit Benchmarks benchmarkreviews.com ausbaldovert werden.
Womit der nächste Punkt,
die Wahl des Dateisystems
eigentlich auch schon geklärt ist. Ext4 wird seit ein paar Kernelversionen als stabil bezeichnet und bietet explizit die SSd Unterstüzung in Zusammenhang mit TRIM und Block layer discard requests.
Sollte man die SSD beim Partitionieren ausreizen, oder sollte man einen Bereich unpartioniert lassen?
Um es kurz zu machen. Lässt man einen bestimmten Bereich unpartitioniert, dann kann sich das Betriebssystem auf den Kopf stellen, es wird nie diesen Bereich der SSD beschreiben können, sieht man vom mutwilligen Beschreiben auf das Raw Device mit dd einmal ab. Der Umkehr Schluss lautet also, dieser Bereich wird vorrangig vom SSD Controller für das Wear Leveling benutzt werden. Meine SSD hat nun 64 GB, Es kursieren Empfehlungen einen Bereich von 10-20% unpartitioniert zu lassen. Nun ich werde 14GB liegen lassen. Der Grund dafür ist noch einmal etwas weiter unten erläutert.
Vollverschlüsselung der SSD
Ich weiß selber nicht, ob ich mir da selber ein Ei lege. Der C'T Artikel SSD-verschlüsseln und auch hardwareluxx a-data-s599-was-kann-der-sandforce-controller erwähnen explizit die Sandforce Controller. Die haben nämlich eine sehr hohe Schreibrate, die vornehmlich durch Datenkompression erreicht wird. Verschlüsselte Daten sind aber nicht komprimierbar. Deshalb partitioniere ich nur 50GB der 64 GB Gesamtkapazität.
Weiterhin stellt sich die Frage, ob ich das bei der Erstellung der verschlüsselten Volumegroup durchgeführte beschreiben mit Zufallswerten nicht lieber abbrechen sollte, um so eine geringere Belastung zu erreichen. Ein brauchbarer Kompromiss wäre, das ich nur die /home Partition verschlüssele und das System ansonsten unverschlüsselt lasse.
Hier fehlt einfach die Erfahrung, vielleicht mache ich im ersten Schritt nur die Minimal Lösung mit verschlüsselter Home Partition.
Welche Bereiche gehören nicht auf einen ssd?
Das Runlevel System von Debian (andere Derivate und SysV kompatible natürlich auch) bieten die Möglichkeit in /etc/default/rcS diverse Einstellungen vorzunehmen.
Zwei interessante Möglichkeiten sind
RAMRUN=no
RAMLOCK=no
Die stehen per default auf no.
RAMRUN betrifft die Dateien unter /var/run/ Dort sind nun nicht unbedingt viele Dateien gespeichert, allerdings sind es alles sehr kleine Dateien, die doch relativ oft upgedatet werden, damit sind sie prädestiniert für ein Filesystem im RAM.
Die selben Argumente treffen auf RAMLOCK zu. Da handelt es sich um Dateien, die unter /var/lock/ gespeichert sind.
Ändert man die Parameter auf yes, werden vom nächsten Reboot an die beiden Verzeichnisse im RAM mittels tmpfs gehalten.
Beide Verzeichnisse enthalten.
das Verzeichnis /tmp ist der Namensgeber für tmpfs, so nimmt es nicht Wunder, das man /tmp auch in der /etc/fstab zum tmpfs Filesystem erklären kann und damit seinem System u.U. erhebliche Writes ersparen kann.
Der folgende Eintrag in der /etc/fstab bewerkstelligt dies:
tmpfs /tmp tmpfs defaults,noatime,nodev,nosuid,mode=1777 0 0
Ein weitere Kandidat für die Auslagerung ins RAM ist /var/log
Nur ist es hier nicht mehr ganz so eindeutig, hat man seine Daemonen auf geschätzig gestellt, dann erntet man als Dank auch eine ständig wachsende Logdatei, z.B. messages. Hat man einen Webserver installiert, erübrigt sich die weitere Betrachtung, denn die sind immer geschwätzig.
Wenn man /var/log wirklich auslagern möchte, benötigt man also entsprechend reichlich RAM. Da muss ein Jeder für sich abwägen, was einem wichtiger ist...
tmpfs /var/log tmpfs defaults,noatime,nodev,nosuid,mode=1777 0 0
wäre demnach der korrekte Eintrag in der /etc/fstab, wenn man sich dafür entscheidet.
Man sollte aber bedenken, das damit Fehlersituationen nicht mehr so leicht zu lokalisieren sind, denn nach einem reboot sind die Logs weg. Man solte dann ggfs. den Eintrag zur Fehlersuche auskommentieren.
Bleibt noch
/swap.
Auf SSD oder im Ram was u.U. durchaus Sinn macht, betrachtet man CompCache bzw. zram oder evtl. ganz darauf verzichten?
Unbedingte Voraussetzung ist swap nur, wenn man nicht genug RAM zur Verfügung hat, oder wenn man suspend to Disk nutzen möchte. Man könnte auch ein File als Swapfile anlegen, die Priorität entsprechend niedrig ansetzen, so das es so gut wie nie, oder eben nur im Notfall benutzt wird.
Oder man definiert eine kleine swap Partition, die man auch mittels "swapiness" so schlecht beurteilt, das sie praktisch nie genutzt wird. Das ist eine Entscheidung, die nicht leicht zu fällen ist, will man ab- und zu auch mal Panorama Aufnahmen erzeugen und bearbeiten, sind 2GB Arbeitspeicher nicht zu reichlich bemessen. Da sollte man schon swap Space vorsehen.
Für die derzeit üblichen Games sind 2GB ausreichend. Auf meinem Tablet PC allemal, weil da eh nur eine integrierte Graphic vorhanden ist und Blockbuster wie Enemy Territory eh nicht in Frage kommen.
Da ich auf jeden Fall wieder ein vollverschlüsseltes System mit Volumegroup aufsetzen werde, ist es nicht so entscheidend, denn ich kann es im nach hinein jederzeit wieder ohne Probleme ändern.
Wer also Swap eingerichtet hat, sollte die Verwendung minimieren. das kann man dauerhaft in der /etc/sysctl.conf einstellen.
Der Parameter vm.swappiness steht nach der default Installation auf 60.
Damit neigt der Kernel eher dazu Swap zu nutzen. Weil die ssd eigentlich schnell ist, ist das auch gar nicht so schlecht, nur wird die Hardware schneller altern.
Ich stelle einen Wert von 10 ein, damit beginnt der Kernel erst Prozesse oder Teile davon auszulagern, wenn alle Reserven bis auf einen kleinen Rest erschöpft sind.
Browser Cache.
Einer der meistgenutzten Anwendungen auf (m)einem Laptop ist der Webbrowser.
Ich benutzt nachezu ausschließlich den Iceweasel 3.5.x
Der Browser verwendet per default einen Festplatten Cache, dieser ist bei mir 50MB groß und wird seiner Natur gemäß auch laufend verändert. Der Firefox (oder Iceweasel) verwendet darüber hinaus aber auch noch einen Cache im RAM. Beim Schieb erfährt man darüber näheres.
Deshalb habe ich mich entschlossen, ganz auf Festplatten Cache zu verzichten, und ihn auf 0 gesetzt.
Natürlich könnte man den cache Ordner des Browsers auch nach /tmp verlinken, das müsste man mal in der Praxis untersuchen......
Dank eines Kommentars bin ich da inzwischen weiter: ich habe den Key in about:config eingerichtet browser.cache.disk.parent_directory; /tmp/browser/
Hier mal der Smart Status;
smartctl 5.40 2010-07-12 r3124 [i686-pc-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Device Model: ADATA SSD S599 64GB
Serial Number: 00000000000000000462
Firmware Version: 3.1.0
User Capacity: 60.022.480.896 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 6
Local Time is: Wed Dec 8 16:41:57 2010 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Auffallend ist nicht nur die sehr kleine Seriennummer und der Firmware stand, sondern auch der niedrige nutzbare Speicher. Dabei steht in der Produktinfo doch 64MB. Sowas 
