Auf einem vorgestern eingerichteten Laptop unter Linux habe ich die eingebaute SATA3 HD gegen eine SSD ausgetauscht.

Gewählt hatte ich die “Samsung SSD 840 PRO” in der 256 GB-Variante. Animiert dazu hatte mich folgender Testbericht:

http://www.guru3d.com/articles_pages/samsung_840_pro_ssd_benchmark_review_test,16.html

Wie die dortigen Vergleiche zeigen, ist das Pro in der Datenträger-Bezeichnung durchaus bedeutsam, weil die Pro-Variante gegenüber der Basis-Variante nochmal deutliche Performance-Vorteile bringt.

Im BIOS muss man für den Betrieb der SSD das SATA-Interface auf AHCI umstellen.

http://wiki.ubuntuusers.de/SSD/Grundlagen

Optimierungstipps findet man z.B. hier:

https://sites.google.com/site/easylinuxtipsproject/ssd-in-opensuse
http://www.linuxbibel.org/ssd_optimieren.html
http://wiki.ubuntuusers.de/SSD/TRIM
http://www.pcwelt.de/ratgeber/Linux-Special-SSDs-unter-Linux-6593528.html
http://wiki.siduction.de/index.php?title=Solid_State_Disks_%28SSDs%29_unter_Linux_optimal_nutzen

Am wichtigsten erscheint es mir bei normaler Nutzung und in dem Fall, dass man keine weitere normale Festplatte verfügbar hat, die Option “noatime” für das “ext4”-Filesystem zu nutzen sowie regelmäßig händisch oder über cron den Befehl

fstrim -v /

abzusetzen. Logs im tempfs unterzubringen ist zwar nett, aber auch eine Übung, die im Ernstfall wertvolle Informationen kosten kann.

Erster Eindruck von der Performance
Ich wurde nicht entäuscht. Unter Opensuse 12.3 erlebte ich für eine normale Desktop-Konfiguration ohne Serverkomponenten

• Shutdownzeiten deutlich unter 2 Sekunden
• Bootzeiten im Anschluss an Grub 2 von unter 4,5 Sekunden (inkl. Hochfahren von KDM – also bis zum grafischen Login).

Da kommen meine als Raid 10 am 3ware-Controller konfigurierten SATA 2 Platten der Workstations nicht mit. Es fehlt ein Faktor 2 bei gleicher Konfiguration. Das setzt sich mit Faktoren von 1.6 bis 2.0 bei Tests mit “bonnie++” zu verschiedenen Lese- und Schreib-Vorgängen so fort.

Die Samsung SSD 840 Pro hält wirklich, was sie verspricht.

Fazit:
Wer seine Linux-Systeme richtig beschleunigen möchte, richte sich eine SSD des genannten Typs als Träger für die Systempartition ein.

Wenn man gegen SSD-Ausfälle gefeit sein möchte, kaufe man sich für etwa den gleichen Preis (rund 205 Euro) zwei “128 GB”-SSD-Platten des hier betrachteten Typs und fahre die im Raid 1 Verbund an einem passenden “SATA 3”-Controller. Andere erstrebenswerte Konfigurationen wie etwa Raid 10 wären für mich auf Basis von SSDs nicht erschwinglich.

User-Daten, Anwendungsdaten, Datenbanken, etc. und alles, wo ein hoher Schreibdurchsatz gegeben ist, lege man dagegen auf konventionellen Platten (in einem geeigneten, performancesteigernden Raid-Verbund) ab – schlicht um die Lebenszeit der SSD zu verlängern.

Ich benutze schon seit langem LSI/3ware-Raid-Controller unter Opensuse. Dabei setze ich gerne das grafische Administrations-Tool “3DM2” für die Verwaltung der Controller-Einstellungen, evtl. Verify-Läufe etc. ein. Diese Tool ist eine Java-basierte Applikation für den Browser.

Seit etwa Ende 2009 gab/gibt es Probleme mit dem 3DM2-Tool in aktuellen Browsern wie Firefox, Chrome, Safari, MS IE9, Opera. Zumindest auf x86_64-Systemen. Das äußerte sich darin, dass der Standardaufruf

https://localhost:888

zu Fehlermeldungen wegen des selbst signierten Zertifikats führte und dass auch nach einem Akzeptieren des Zertifikats Netzwerkfehler hochkamen – vermutl. wegen eines falschen oder veralteten SSL-Algorithmus. Im Ergebnis wurde die 3ware-3DM2-Admin-Oberfläche nicht angezeigt.

Dies war auch unter der von LSI/3ware herausgegebenen “9.5.3_codeset”-SW-Paket-Version noch der Fall.

Ich hatte mir bis heute dadurch geholfen, dass ich für “3DM2” die Browser “Epiphany” oder “Konqueror” benutzte. Die erlaubten noch den Aufbau der Seiten. (Vielleicht weil hier laxer mit Sicherheitsanforderungen umgegangen wird ???)

Doch nun funktioniert die Sache mit einem aktuellen Codeset wieder. Heute habe ich mir jedenfalls das aktuelle “9.5.5_codeset”-SW-Paket von folgender Seite

http://www.lsi.com/channel/support/Pages/Download-Results.aspx?productcode=P00080&assettype=Software&component=Storage%20Component&productfamily=RAID%20Controllers&productname=3ware%209650SE-4LPML

heruntergeladen. Man bekommt dann ein ISO-Image-File auf die Platte. In meinem Fall auf ein aktuelles Opensuse 12.2 (x86_64)-System.

Das ISO-File mounted man dann (als root) direkt in Form eines “Loopback-Devices” (s. hierzu http://www.cyberciti.biz/tips/how-to-mount-iso-image-under-linux.html)

#   mount   -o   loop /extras/Updates/3ware/955_codeset/9.5.5.1-Codeset-Complete.iso   /mnt/

und startet dann mit

#   cd   /mnt/packages/installers/tools/linux
#   ./install.sh -i

die Installation. Man behält bei der entsprechenden Rückfrage am besten den Inhalt des Konfigurationsfiles unter
“/etc/3dm2/3dm2.conf” bei – sprich : man entscheidet sich für die Option, die das File unangetatstet lässt.

Nach dem Abschluss der Installation muss man den Service TDM2-Service neu starten.

# cd   /etc/init.d/
# ./tdm2   restart
redirecting to systemctl
redirecting to systemctl
Stopping 3ware DiskSwitch Daemon: done
redirecting to systemctl
Starting 3ware DiskSwitch daemon: done

Danach funktioniert der Aufruf von 3DM2 über https://localhost:888 auch unter Chromium/Chrome, Firefox und Opera wieder !

Auf meinem Laptop fiel mir nach ein paar Updates auf, dass folgende Botschaft gleich am Anfang des Bootvorgangs erscheint:

FATAL: Module ata_piix not found
FATAL: Error running install command for ata_piix

Faktisch geschieht dies bereits während des ersten Ladens der Module von der “initrd”.

Die Meldung hört sich beunruhigend an, sie es in meinem Fall aber nicht. Denn trotz der Meldung läuft auf meinem Laptop, den ich nun schon ein paar Jahre unter Opensuse betreibe, alles ganz normal. Was also ist der Hintergrund der Fehlermeldung?

Checkt man auf dem gebooteten System die geladenen Module, so findet man, dass ein Modul “ata_piix” tatsächlich nicht geladen ist.

lap3lux64:~ # lsmod | grep ata_piix
lap3lux64:~ #

Dennoch zeigt ein Blick in die System-Konfiguration mittels “hwinfo” oder Yast2’s “Hardware-Information” sehr schnell, dass für die Harddisk und auch ein an Bord befindliches DVD-Laufwerk der benötigte Treiber “ata_piix” eingesetzt wird:

lap3lux64:~ # hwinfo | grep ata_piix

   0170-0177 : ata_piix
   01f0-01f7 : ata_piix
   0376-0376 : ata_piix
   03f6-03f6 : ata_piix
   bfa0-bfaf : ata_piix
   14:   244245    0    IO-APIC-edge    ata_piix
   15:   223066    0    IO-APIC-edge    ata_piix
   ata_piix: /devices/pci0000:00/0000:00:1f.2
   ata_piix: module = ata_piix
i/o:0 0x0170 – 0x0177 (0x08) “ata_piix”
i/o:0 0x01f0 – 0x01f7 (0x08) “ata_piix”
i/o:0 0x0376 – 0x0376 (0x01) “ata_piix”
i/o:0 0x03f6 – 0x03f6 (0x01) “ata_piix”
i/o:0 0xbfa0 – 0xbfaf (0x10) “ata_piix”
irq:0 14 ( 244245) “ata_piix”
irq:0 15 ( 223066) “ata_piix”
   ata_piix: /devices/pci0000:00/0000:00:1f.2
   ata_piix: module = ata_piix
   E: DRIVER=ata_piix
<7>[ 0.846528] ata_piix 0000:00:1f.2: version 2.13
<6>[ 0.846545] ata_piix 0000:00:1f.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17
<6>[ 0.846551] ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ]
<7>[ 0.846596] ata_piix 0000:00:1f.2: setting latency timer to 64
<6>[ 0.846951] scsi0 : ata_piix
<6>[ 0.847068] scsi1 : ata_piix
Driver: “ata_piix”
Driver Modules: “ata_piix”
Driver: “ata_piix”, “sd”
Driver Modules: “ata_piix”
Driver: “ata_piix”, “sr”
Driver Modules: “ata_piix”
lap3lux64:~ #

Die Ursache dafür ist, dass man bei dem aktuellen Kernel 3.1.10-1.16, den Opensuse anbietet, das benötigte “ata_piix”-Modul nicht mehr extra laden muss. Es ist bereits in den Kernel einkompiliert. Dies erkennt man an der Konfigurationsübersicht für den aktuellen Kernel. Unter Opensuse findet man die entsprechende Datei unter dem Verzeichnis “/boot” :

Die Datei “boot/config-KERNELVERSION” – in meinem Fall “/boot/config-3.1.10-1.16-default” – enthält Informationen zur aktuellen Kernelkonfiguration, die die Opensuse-Leute für das System vorgesehen haben. U.a. findet man:

#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=y
CONFIG_SATA_MV=m
CONFIG_SATA_NV=m
CONFIG_SATA_PROMISE=m
CONFIG_SATA_SIL=m
CONFIG_SATA_SIS=m
CONFIG_SATA_SVW=m
nCONFIG_SATA_ULI=m
CONFIG_SATA_VIA=m
CONFIG_SATA_VITESSE=m

Der Treiber ist also bereits in den Kernel intergriert und nicht als nachzuladendes Modul vorgesehen.

Zur Beseitigung der ata_piix-Fehlermeldung genügt es deshalb, das Treibermodul aus der Datei

/etc/sysconfig/kernel

zu entfernen. Betroffen ist die Zeile:

INITRD_MODULES=”ata_generic processor fan ata_piix”

aus der man den Eintrag “ata_piix” schlicht löscht.

Am besten macht man das unter Opensuse allerdings mit YasT2’s “Editor für /etc/sysconfig”, da dabei gleich auch noch die “initrd” neu erstellt wird. Siehe im sysconfig-Editor die Einstellungen unter

“System >> Kernel >> INITRD_MODULES”

.
Ansonsten muss man den Befehl “SuSEconfig” ausführen und “auch noch den Befehl mkinitrd” absetzen.

Bei den anschließenden Bootvorgängen ist die Meldung dann verschwunden.

Ich denke, das ganze “Problem” ist dadurch entstanden, dass das Linux-System auf dem Laptop mehrere Male auf die neueste Opensuse-Version upgegradet wurde. Die ursprünglichen Einstellungen zur “initrd” aus einer Zeit, als das ata_piix-Modul noch separat nachgeladen wurde, bleiben dabei offenbar unverändert.

Also keine Panik, wenn die obige Meldung auftaucht !