Solid State Disks (SSDs) unter Linux optimal nutzen

Aus Siduction Wiki DE
Wechseln zu: Navigation, Suche


Gute, optimal eingestellte SSDs sind bekanntlich im Optimalfall um ~ Faktor 5-7 schneller als herkömmliche HDDs. Sie sind aber auch noch recht teuer, momentan um die 2 €/GByte. Das prädestiniert sie zur Systemplatte. Hier können sie ihre Stärken ausspielen: sehr hohe Leseraten und kaum messbare Zugriffszeiten. Hinzu kommt, dass SSDs kaum Energiehunger verspüren und man ihnen, im Gegensatz zu HDDs, beim Rechnen nicht zuhören kann/muss.

Die kleinsten angebotenen Kapazitäten mit Größen von 60 - 120 GByte sollten als Systemdisk ausreichen; zum Datengrab eignen sich SSDs sowieso vom Prinzip her nicht. Alle diese Gründe prädestinieren sie z. B. auch für HDCP-Systeme.

Ich werde im folgenden beleuchten, was der geneigte Linuxer tun muss, um seine SSD zur Höchstleistung zu treiben und sie auch dort zu halten. Früher hieß es immer: es gibt nichts Besseres als mehr RAM um einen Rechner zu beschleunigen. Heute ist die SSD an diese Stelle getreten.

Ich habe seit einigen Tagen eine OCZ Vertex 3 und habe für dieses Kleinod einen Rechner auf Basis von Intels Sandy Bridge mit einem Core i7 2600k und einem Noctua NH-C14 CPU-Kühler in einem Gehäuse von Antec mit 4 Lüftern gebaut. Die Vertex 3 reizt die SATA3-Schnittstelle mit ihren 6 GBit/s Durchsatz fast völlig aus. Benchmarks im Verlauf des Artikels beziehen sich auf diesen Rechner. Ich werde auch versuchen, am Ende Kaufempfehlungen für jeweils SATA2 und SATA3 zu geben.

Bitte behaltet im Hinterkopf, das SSD und ihre Unterstützung durch Betriebssysteme ein Konzept in Entwicklung sind. Viele Informationen im Netz sind veraltet, Dinge, die bei der ersten Generation von SSD nötig waren, sind heute überflüssig. Ich habe versucht, in diesem Artikel sozusagen auf Messers Schneide zu wandeln. Es mag Einstellungen geben, die mit dem nächsten Kernel überflüssig werden. Ich habe auf jeden Fall darauf geachtet, keine Tweaks zu empfehlen, die, selbst wenn sie obsolet werden, schaden könnten.

Organisationsstruktur von Solid State Drives

Zum besseren Verständnis des Folgenden braucht es einen kurzen Abriss über die Organisation von SSDs. Sie speichern Daten in Nand-Chips. Es gibt SLC-Nand und MLC-Nand. Die meisten Consumer-Drives nutzen das günstigere MLC-Nand. Physikalisch gibt es zwischen beiden keinen Unterschied, sie unterscheiden sich lediglich in der Art, wie sie die Daten speichern. Eine Zelle SLC-Nand speichert genau 1 Bit, bei MLC sind es derer 2. Nand-Zellen sind in Gruppen zu Pages organisiert. Pages sind die kleineste Einheit, die auf einer SSD gelesen oder geschrieben werden kann und ist heute fast immer 4 KB groß. Pages wiederum sind in Blocks organisiert. Bei heutigen SSDs sind das meist 128 Pages in einem Block, also 512 KB. Ein Block ist die kleinste Einheit, die auf einem Nand-Flash-Device gelöscht werden kann. Das nennt man technisch EBS (erase block size). Rekapitulierend: man kann auf Pages lesend/schreibend zugreifen, löschen kann man nur Blocks, also 128 Pages auf einmal.

Das nächste Organisationslevel wäre eine Plane (1024 Blöcke=512 MB) und so weiter. Kurz noch was zum Buildprozess: Die meisten Nand-Flash-Chips wurden bis vor kurzem im 34 nm Prozess gefertigt, was 32GBit MLC NAND (4 GByte) pro Die erlaubte. Mit dem 25 nm Prozess, in dem die neuesten SSDs des 1. Quartals 2011 erzeugt wurden, verdoppelt sich das auf 64 GBit (8 GByte) pro Die. Im Endeffekt wird das zu Preissenkungen führen, jedoch aus mehreren Gründen nicht sofort. Einerseits sind die Dies für den 25 nm Prozess teurer als die für 34 nm, auf der anderen Seite dauert es auch eine gewisse Zeit, bis die Ausbeute, der sogenannte yield des neuen Prozesses genauso gut ist wie beim alten 34 nm Prozess.


BIOS

Nun gehen wir aber mal davon aus, ihr habt euch den Luxus einer SSD gegönnt und haltet sie in Händen bzw. habt sie an die entsprechende SATA-Schnittstelle angeschlossen. Wie geht's nun weiter?

Als allererstes werfen wir einen Blick ins BIOS, und zwar bei den SATA Einstellungen. Erst mal schauen wir, ob der entsprechende Port auch aktiviert ist. Dann stellen wir sicher, dass der Modus AHCI aktiv ist. (alternativ RAID, falls ihr 2 SSDs habt). Da wir schon einmal vor Ort sind, sollten wir auch gleich nachsehen ob es eine Option write back caching gibt. Falls ja, bitte aktivieren, ich komme später darauf zurück.

Partitionierung

Die nächsten Überlegungen gelten der Partitionierung der Platte. Hier unterscheidet sich das folgende Vorgehen je nachdem, ob das Mainboard ein konventionelles BIOS oder den Nachfolger (U)EFI verwendet. Eine saubere Ausrichtung der Partition(en) ist ziemlich essentiell für die optimale Performance genauso wie für die Langlebigkeit der Platte. Die Ausrichtung sollte sich auf jeden Fall an der EBS (erase block size=meist 512 KB) oder einem Vielfachen davon orientieren. Wenn wir keine saubere Ausrichtung haben, erzeugen wir eine Menge unnötiger Schreib/Lese/Lösch-Zyklen, weil die Blockgröße des Dateisystems nicht mit der EBS des Controllers übereinstimmt.

GPT ist Teil des EFI-Standards, der das BIOS in PCs ersetzen soll, kann aber unter Linux auch mit heutigen BIOSen verwendet werden. Windows7, Vista und Server 2008 erlauben Booten per GPT nur mit UEFI. GPT ist der Nachfolger der MBR-Partitionstabelle.

Partitonierung mit GPT (GUID Partition Table)

Das entsprechende Tool für fdisk bei GPT ist gdisk. Es sollte in den Repositories der Linux-Distros vorhanden sein. Unter Debian geben wir ein:

apt-get update && apt-get install gdisk

Dann starten wir gdisk unter Angabe des Device:

root@devbox:# gdisk /dev/sda
GPT fdisk (gdisk) version 0.6.13


Partition table scan:
MBR: not present
BSD: not present
APM: not present
GPT: not present

Creating new GPT entries.

Jetzt erstellen wir eine neue Partitionstabelle:

Command (? for help): o

This option deletes all partitions and creates a new protective MBR.

Proceed? (Y/N): y

Nun legen wir die Partition an:

Command (? for help): n

Partition number (1-128, default 1): #pressed enter to accept default#
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#
Information: Moved requested sector from 34 to 2048 in
order to align on 2048-sector boundaries.
Use 'l' on the experts' menu to adjust alignment
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G
Current type is 'Linux/Windows data'
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#

Changed type of partition to 'Linux/Windows data'

Das Ergebnis:

Command (? for help): p

Disk /dev/sda: 125045424 sectors, 59.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 125045390
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number Start (sector) End (sector) Size Code Name

1 2048 20973567 10.0 GiB 0700 Linux/Windows data

Partition schreiben und gdisk verlassen:

Command (? for help): w


Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!

Do you want to proceed, possibly destroying your data? (Y/N): y
OK; writing new GUID partition table (GPT).
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.

The operation has completed successfully.

Außer der Manpage gibt es zu gdisk nicht wirklich viel Dokumentation, zumindest nicht auf deutsch. Einen guten Überblick über die Parameter gibt: http://www.rodsbooks.com/gdisk/walkthrough.html

Jetzt formatieren wir die SSD mit dem Filesystem ext4:

# mkfs.ext4 /dev/sda1

Wir kennen von USB-Sticks die Empfehlung, als Dateisystem ext2 zu verwenden. Diese Empfehlung findet man auch vereinzelt für SSDs. Hier muss jeder selbst entscheiden, ob er zugunsten längerer Lebenszeit auf die Sicherheit des Journalings verzichtet. Bei SSD setze ich auf ext4, ich mag meine Daten. Sollte man auf das Journaling verzichten wollen, macht es Sinn, anstelle von ext2 besser ext4 zu verwenden und per tune2fs das Journaling auszuschalten. Die Tipps im Netz über den Sinn eines abgeschalteten Journaling halte ich allerdings für veraltet. Das Wear Levelling moderner SSDs sorgt für das gleichmäßige Altern der Zellen, so dass ich für die Sicherheit eines Journals plädiere.

Das gleiche Vorgehen wenden wir an, falls mehr als 1 Partition gewünscht sind.

Herkömmliche Partitionierung mittels MBR (Master Boot Record)

Der Methode per GPT ist klar der Vorzug zu gewähren, ich will aber auch die korrekte Ausrichtung der Partition(en) am Beispiel MBR erläutern. Hierzu setzen wir das Tool fdisk ein. Bei fdisk müssen wir heads und sectors in einer Weise definieren, dass sie mit dem EBS der SSD oder Multiplen davon korrespondieren. Dazu rufen wir fdisk folgendermaßen auf:

# fdisk -H 32 -S 32 /dev/sda
The number of cylinders for this disk is set to 15711.

There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): o
Building a new DOS disklabel with disk identifier 0x8cb3d286.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

The number of cylinders for this disk is set to 15711.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-15711, default 1): 2
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Das Ergebnis überprüfen wir mit:

# fdisk -lu /dev/sda
Disk /dev/sda: 120 GB, 120056361856 bytes

32 heads, 32 sectors/track, 152638 cylinders
Units = cylinders of 1024 * 512 = 524288 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x76b978dc

Device Boot Start End Blocks Id System

/dev/sda1 2 14593 117218241 83 Linux

Wichtig ist hier die Zeile: 32 heads, 32 sectors/track, 14593 cylinders Wenn wir bei fdisk nicht -H 32 -S 32 angegeben hätten, sähe die Zeile so aus: 255 heads, 63 sectors/track, 14593 cylinders und die Partition wäre für das blockweise Löschen einer SSD nicht korrekt ausgerichtet.

Hier ist zu bedenken, dass GPT erst ab Windows 7 unterstützt wird. Bei Dual-Boot mit Windows XP oder Vista sollte man also die Linux-Tools zum partitionieren verwenden.

Wieso sprechen wir von Löschen und nicht von Überschreiben?

Nand-Flash kann nicht überschrieben werden. Die Zelle muss gelöscht werden, bevor sie neue Daten aufnehmen kann. Wir haben oben gelernt, dass das blockweise passiert und haben die Partitionierung entsprechend angelegt. Wie wir aber von USB-Sticks bereits wissen, verträgt Nand-Flash nur begrenzte Schreibzyklen. Dies trifft auch auf die NAND-Chips in SSDs zu, allerdings haben sie im Gegensatz zu USB-Sticks einen intelligenten Controller. Hier kommen die Stichworte TRIM und Wear Levelling ins Spiel. Jede Zelle einer modernen SSD verträgt etwa 3000 Schreibvorgänge. Hört sich wenig an, reicht aber dank Wear Levelling für Jahre an Betriebsstunden. Durch Wear Levelling wird sichergestellt, dass alle Zellen der SSD so gleichmäßig wie möglich gelöscht/beschrieben werden. Das eigentliche Löschen leitet der TRIM-Befehl ein. TRIM ist die Kommunikationsschnittstelle zwischen Betriebssystem und SSD-Controller. TRIM markiert vom Betriebssystem gelöschte oder als korrupt gemeldete Datenblöcke und teilt dies dem Controller mit. Die Daten werden dann nicht mehr weiter mitgeschrieben und beim nächsten Löschen des entsprechenden ERASE BLOCK entfernt. TRIM wird heute von Windows 7, OS X an 10.7 und Linux ab Kernel 2.6.33 unterstützt.

Einstellungssache

Wenn wir unser Linux installiert haben, sollten wir einige sinnvolle Einstellungen vornehmen um die Geschwindigkeit und Langlebigkeit unserer SSD zu gewährleisten. Dazu schauen wir als erstes in die Datei /etc/fstab. Hier finden wir für die SSD eine Zeile wie etwa

UUID=0f88611c-2c2b-48ce-...... / ext4 defaults, relatime 0 1

Hier ändern wir als erstes relatime in noatime. Damit stellen wir sicher, dass nicht bei jedem Lesevorgang der Zeitstempel einer Datei geändert wird. Nun schalten wir noch TRIM ein, indem wir den Mountbefehl discard anhängen. Unsere Zeile sieht dann so aus:

UUID=0f88611c-2c2b-48ce-...... / ext4 defaults, noatime, discard 0 1

Der discard-Befehl scheint nicht überall einwandfrei zu funktionieren und < 2.6.38 nicht wirklich sinnvoll zu sein. Im Internet gibt es Berichte, dass nach Einschalten des Befehls der Rechner Hänger im Bereich von 1 Sekunde produziert. Allerdings sind die Berichte auch meist auf Kernel 2.6.35 und 2.6.36 bezogen. Hier mit derzeit 2.6.38 passiert das jedenfalls nicht. Also bitte beobachten.

TRIM testen

Nachdem wir den Befehl mount benutzt haben, um die Änderungen an der fstab zu übernehmen, wollen jetzt mal testen, ob TRIM automatisch per discard funktioniert:

cd  / #oder den richtigen Pfad zu der SSD
dd if=/dev/urandom of=tempfile count=100 bs=512k oflag=direct 
hdparm --fibmap tempfile  #hiermit lesen wir die belegten Sektoren des tempfile aus

Von der Ausgabe kopieren wir uns die Zahl unter "begin_LBA" und setzen sie im nächsten Befehl ein:

hdparm --read-sector 1234567 /dev/sda   #ersetze 1234567 mit der Zahl aus dem vorigen Befehl und /dev/sda mit dem korrekten Gerätenamen#

Ergebnis sollte ein längerer String sein.

rm tempfile
sync
hdparm --read-sector 1234567 /dev/sda  #1234567 ersetzen, siehe oben#</blockquote>

Direkt nach dem Löschen des Temp-Files werden die Sektoren noch nicht leer sein. Wiederholen wir den letzten Befehl (hdparm --read-sector...) nach einer Weile, sollten nur noch Nullen herauskommen. TRIM works!

Wer Probleme mit discard hat, kann auch das Skript wiper.sh aus dem Paket hdparm per cronjob 1 mal per Woche/Monat verwenden oder das Tool DiskTrim von http://disktrim.sourceforge.net/ verwenden. Vorher sollte man sicherstellen, dass die SSD auch TRIM unterstüzt. Manche ältere SSD braucht dazu ein Firmware-Update. Die Firmware-Version verrät uns der Befehl:

hdparm -iv /dev/sda

Da wir schon in der fstab sind, sollten wir, sofern wir genügend RAM haben (>=4 GB), /tmp ins RAM verschieben. Das tun wir mit den Zeilen:

tmp        /tmp          tmpfs defaults,nodev,nosuid,mode=1777 0 0 
shm        /run/shm      tmpfs defaults,noatime 0 0 

Jetzt haben wir schon einiges an unnötigen Schreibzugriffen eliminiert. Wer möchte, kann /tmp in der Größe limitieren durch den Parameter size=512M oder size=4G in obiger Zeile. Wer viel kompiliert, kann auch dies direkt in /dev/shm tun. Sinnvoll erscheint das ab 8 GB RAM, so dass man mindestens 4 GB per size= festlegen kann.

Browser-Cache ins RAM auslagern

Wir können aber noch mehr ins RAM auslagern. Ich zeige mal am Beispiel Firefox, wie wir das Caching oder auch größere Teile unserer Daten, die beim Browsen anfallen, ins RAM auslagern. Hierzu nutzen wir /run/shm, ein shared memory Directory, dass zwar im RAM wohnt, sich ansonsten aber wie ein normales Verzeichnis verhält. In der Firefox-Adresszeile geben wir about:config ein und bestätigen die Warnung. Durch einen Rechtsklick ==>Neu ==>String erstellen wir einen neuen Eintrag namens:

browser.cache.disk.parent_directory

Nach einem Doppelklick auf den neu erstellten String weisen wir ihm folgenden Wert zu:

/run/shm/firefox-cache

Nun erstellen wir in der Konsole noch das Directory:

mkdir -m0700 /run/shm/firefox-cache

Nach einem Firefox Neustart wird zukünftig ins RAM gecached. Analog ist bei anderen Browsern vorzugehen.

Weitere Optimierungen

Die bisherigen Optimierungen sind alle sinnvoll und notwendig und haben einen Effekt sowohl für die Geschwindigkeit als auch für die Langlebigkeit der Platte. Diese Tweaks sollte jeder Nutzer nachvollziehen, auch wenn die Platte natürlich ohne (schlechter) läuft. Die jetzt folgenden Optimierungen tendieren in Richtung frickeln, was nicht heißen soll, dass sie keinen Effekt haben. Sie können die Geschwindigkeit der SSD in verschiedenen Teilbereichen weiter optimieren. Da das Netz hier eine Unzahl an sinnigen und unsinnigen bis gefährlichen Tipps bereithält, werde ich etwas aussieben.

Scheduler

Der Scheduler des Kernels ist default nicht auf SSDs ausgelegt. Macht Sinn, denn wer hat schon eine? Wir wollen aber das Beste aus unserer SSD rausholen und testen andere Scheduler.

cat /sys/block/sda/queue/scheduler

zeigt unter siduction

noop deadline [cfq]

wobei der in Klammern stehende [cfq] per default eingestellt ist. Beide Optionen, noop, sowohl als auch deadline sind eher auf die Gegebenheiten bei SSDs abgestimmt. Also wollen wir sie erst mal testen.

# echo deadline > /sys/block/sda/queue/scheduler

Ein anschließendes

# cat /sys/block/sda/queue/scheduler
zeigt
noop [deadline] cfq
Das heißt, bis zum nächsten Reboot wird nun deadline als Scheduler benutzt. Genauso können wir verfahren, um noop zu testen. Ich zeige am Ende noch ein paar simple kleine Benchmarks, wie man die Auswirkungen schnell testen kann, bevor man sich für einen Scheduler festlegt.

Hat man sich für einen entschieden, kann man ihn festlegen per Eintrag in /etc/rc.local:

echo noop > /sys/block/sda/queue/scheduler

Falls wir anfangs im BIOS die Option write back caching gefunden und aktiviert haben, wollen wir sie jetzt umsetzen. Dafür installieren wir, falls nicht vorhanden das Programm hdparm. Das macht in jedem Fall Sinn, denn es ist auch der einfachste Benchmark den wir haben.

# apt-get update && apt-get install hdparm

Dann setzen wir zum Aktivieren von write back caching folgenden Befehl ab:

# hdparm -W1 /dev/sda

Auch dieser Befehl verliert mit Reboot seine Wirkung. Permanent wird auch er durch einen Eintrag in /etc/rc.local.

Bei den Optionen für Mountbefehle in etc/fstab findet man im Internet zum Teil Vorschläge, die Optionen commit= und barrier= zu setzen. Ich möchte von beiden abraten. commit= ist die Rate, mit der das Schreibintervall gesetzt wird. Es ist defaultmäßig auf 5s. Ich finde es sicherheitsrelevant, diesen Wert nicht zu erhöhen. barrier= ist ein Feature von ext4, bei dem zuerst (zusammenhängende) Daten vor einer Barriere geschrieben werden, dann erst (zusammenhängende) Daten dahinter. barrier=0 erhöht leicht die Performance für den Preis der Datensicherheit.

Benchmarking

Nur als kleine Warnung vorweg: Man kann eine SSD auch zu Tode benchmarken. Also: macht die nötigen Benchmarks, um zu den für euch optimalen Einstellungen zu kommen. Sichert die Ergebnisse für spätere Vergleiche. Aber bitte nicht zum Angeben jedem , der nicht bei 3 auf dem Baum ist, eine komplette Benchmark-Suite um die Ohren hauen. Wenn bei euch im Gegensatz zu professionellen Reviews das ein oder andere Megabyte fehlt, so ist dies dem Umstand geschuldet, dass diese Leute das professionell und meist auf eine nackte Platte machen.

Eine Auswahl an Benchmarks

Der einfachste und schnellste Benchmark ist hdparm

#  hdparm -Tt /dev/sda
Timing cached reads: 23188 MB in 2.00 seconds = 11605.90 MB/sec
Timing buffered disk reads: 1188 MB in 3.00 seconds = 395.48 MB/sec

Aussagekräftiger ist dd:

$ cd /path/to/SSD
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc
1024+0 records in

1024+0 records out

1073741824 Bytes (1,1 GB) kopiert, 2,18232 s, 492 MB/s

oder auch

# hdparm --direct -Tt /dev/sda


Jetzt löschen wir den buffer-cache, um die genaue Lesegeschwindigkeit direkt von der Platte zu bekommen:

# echo 3 > /proc/sys/vm/drop_caches
$ dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 records in

1024+0 records out

1073741824 Bytes (1,1 GB) kopiert, 2,55234 s, 421 MB/s

Jetzt lassen wir das letzte File im buffer-cache und messen dessen Speed:

$ dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 Datensätze ein

1024+0 Datensätze aus

1073741824 Bytes (1,1 GB) kopiert, 0,122594 s, 8,8 GB/s

Wer hier eine akkurate Zahl braucht, sollte den letzten Befehl 5 mal ausführen und die Werte mitteln. Die eingetragenen Werte habe ich mit meiner OCZ Vertex 3 gemessen. Zwei etwas aufwendigere Benchmarks sind Bonnie++ und Compilebench.

Und zum guten Schluss noch die versprochenen Kaufempfehlungen:

für die SATA III 6 GB/s Schnittstelle: OCZ Vertex 4 (128GB) für derzeit ~ 90 € (stand 15.09.2012)
Begründung: ganz einfach: im Consumer-Bereich kommt keine andere Platte auch nur ansatzweise heran

für die SATA II 3 GB/s Schnittstelle: OCZ Vertex 3 Max IOPS (240GB) für derzeit ~ 130 € (stand 15.09.2012)
Begründung Die Vertex 3 ist auch sehr schnell und bei Preis/Gb kaum zu unterbieten

Und nein, ich habe keinen Vertrag mit OCZ :) Die Produkte sind einfach dank optimal getunter SandForce Controller weit vorne.

Ich werde in der nächsten Zeit noch einiges ergänzen und einige Mythen aus dem Netz entlarven. Fürs erste sollte aber jeder mit den obigen Informationen eine SSD optimal in Betrieb nehmen können.

Quelle:

Blog auf http:.//siduction.org