Da denkt man, das mit dem Einsatz von SSD das Leben im Bereich der großen schnellen Storage-Systeme ein wenig besser wird. Ja, das Zeugs hat noch seine Haken und Ösen und wird im Laufe der Zeit langsamer und verliert vielleicht auch Platz aber das es nicht einmal ein Jahr im Einsatz bereits böse verreckt, das hätte ich nicht gedacht.
Vor ca. 8 Monaten verbaute ich in einem mit geringem Schreibzugriff genutzten System eine 30 GB SSD der Firma Super Talent (STT_FTM32GX25H) als System-”Festplatte”. Darauf lief ein braves Centos bis vor einigen Tagen.
Während ich auf dem System (irrwitzigerweise zum Backup machen) eingeloggt war ging die Welt unter. Das Backup (auf ein iscsi-network device, also nicht auf die SSD) failte mit der Nicht-Lesbarkeit von Dateien. In den dmesg-Ausgaben taucht die Meldung auf, das das Root-Filesystem auf Read-Only ging und de-fakto ging die Welt der Maschine unter.
Nun gut, aktive Dienste auf ein anderes System umgeschaltet und einen Reboot inittiert der dann schon zeigte das eigentlich nichts mehr gehen wird – das Root-Filesystem konnte nicht gemounted werden. Ok, Rescue System gebootet und nachgeschaut, fsck sagt es geht nichts mehr, abgebrochen und den Datenbestand aufgegeben.
In einem Testsystem dann die SSD mal ein wenig getestet, und was durfte ich da sehen – Dinge die man eigentlich nicht glaubt, man würde davon ausgehen, das diese durch die SSD von selbst beseitigt werden.
root@sysresccd /root % badblocks -f -w /dev/sda
/dev/sda is apparently in use by the system; badblocks forced anyway.
3546048
3546049
3546050
3546051
3546052
3546053
3546054
3546055
7562272
7562273
7562274
7562275
7562276
7562277
7562278
7562279
Das ging dann noch einige Zeit so weiter. Spannend sind dabei die 4k Blöcke, d.h. 8×512 Bytes am Stück waren kaputt. Warum ist das so ?
Nun gut, was kaputt ist, das ist halt kaputt und man probiert damit andere Dinge. Also das gleiche Kommando noch einmal und nun kam das echte Staunen:
root@sysresccd /root % badblocks -f -w /dev/sda
/dev/sda is apparently in use by the system; badblocks forced anyway.
3969808
3969809
3969810
3969811
3969812
3969813
3969814
3969815
5012672
5012673
5012674
5012675
5012676
5012677
5012678
5012679
Mehr davon ?? Sehr spannend. Viele und vor allem: ANDERE !! Die Bad-Blocks haben also ihre Location verändert bzw. bei dem was auch immer die SSD da so veranstaltet hat sind es mehr bzw. andere geworden. Natürlich konnte ich es danach dann nicht mehr lassen:
root@sysresccd /root % badblocks -s -v -f -w /dev/sda
/dev/sda is apparently in use by the system; badblocks forced anyway.
Checking for bad blocks in read-write mode
From block 0 to 31266647
Testing with pattern 0xaa: done
Reading and comparing: done
Testing with pattern 0x55: done
Reading and comparing: 202816% done, 16:20 elapsed
202817
202818
202819
202820
202821
202822
Es wurden wieder mehr und andere. Nach einigen Läufen dann aber wiederholbar, auch nach dem Ein- und Ausschalten:
root@sysresccd /root % badblocks -s -v -f -w /dev/sda
/dev/sda is apparently in use by the system; badblocks forced anyway.
Checking for bad blocks in read-write mode
From block 0 to 31266647
Testing with pattern 0xaa: done
Reading and comparing: done
Testing with pattern 0x55: done
Reading and comparing: done
Testing with pattern 0xff: done
Reading and comparing: done
Testing with pattern 0x00: done
Reading and comparing: done
Pass completed, 0 bad blocks found.
Merke: SSDs sind anders. Das tolle ist, das es auf der OS-Seite keine Read-Errors gab, nur es gab eben andere Daten zurück als hingeschrieben wurden. Quasi-Daten-Roulette.
Wenn man nun brav hinschriebt auf so ein Device, block 1-20 und dann Block 1,2,8,9,3,4,5,6,7,11-20 in der Reihenfolge kommentarlos zurück-bekommt, manchmal zumindest, dann ist das großes Kino.
Das sind dann die Momente wo ein Mirror von zwei SSDs auch nichts hilft, dann weiß man nachher nicht einmal mehr welche der Devices kaputt ist aber ist sich total sicher, das die Daten es sind. Datenrettungsansätze kann man auch vergessen, denn bei fast allen Filesystemen steht nicht im Block welcher der Block ist.
Bei den guten alten Festplatten konnte man sich wenigstens noch drauf verlassen das nach Block 1 der Block 2 kam. Und wenn der nicht kam, dann kam er nicht und nicht was anderes.
SSDs im Server ohne Cryptografisch-gesicherte Filesysteme – nein, das macht man nicht. SSDs für Daten die es nur einmal gibt und nicht in Mehr-Generationen-Backups über lange Zeiten, nein das macht man auch nicht. Das schlimmste ist die Kommentarlosigkeit des Datenverschwindens/Tauschens. Das ist geradezu obszön gefährlich.
