Ist ein Software-RAID1 mit SSD problematisch?

[Jimini]

Guten Morgen,

nachdem mir nun binnen einer Woche nacheinander beide SSD in einem Software-RAID1 weggeklappt sind, mache ich mir gerade Gedanken, ob SSD generell dafür geeignet sind. Es handelt sich um ein TeamGroup L3 SSD 60GB (Firmware S9FM01.8) und ein SanDisk SDSSDP064G (Firmware 3.2.0). Beide stecken in einem Linux-System und sind Teil von zwei Software-RAID1. Beide Laufwerke sind nicht direkt mit dem Mainboard verbunden, sondern stecken an einem DeLock-SATA-Controller. Diese Konstellation arbeitet glaube ich seit Anfang des Jahres zuverlässig. Der Controller war schon vor einigen Jahren ohne Probleme im Einsatz.

Am 31.8. stieg erstmalig das SanDisk-SSD aus beiden Arrays aus. Ein direktes Hinzufügen war nicht möglich, also steckte ich das Laufwerk kurz komplett ab und schloss es dann wieder an. Danach konnte ich es wieder zu den Arrays hinzufügen.
Am 6.9. geschah das gleiche mit dem TeamGroup-SSD.

Zumindest die SMART-Daten sind meines Erachtens unauffällig:
TeamGroup L3 SSD 60GB

  1 Raw_Read_Error_Rate     0x000a   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       1261
 12 Power_Cycle_Count       0x0012   100   100   000    Old_age   Always       -       22
168 Unknown_Attribute       0x0012   100   100   000    Old_age   Always       -       0
170 Unknown_Attribute       0x0013   100   100   010    Pre-fail  Always       -       7
173 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       26738753
192 Power-Off_Retract_Count 0x0012   100   100   000    Old_age   Always       -       1
194 Temperature_Celsius     0x0023   070   070   030    Pre-fail  Always       -       30
196 Reallocated_Event_Count 0x0000   100   100   000    Old_age   Offline      -       0
218 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       0
241 Total_LBAs_Written      0x0012   100   100   000    Old_age   Always       -       1937145

Leider sind hier nicht alle Attribute bekannt. Aber der SMART-Selbsttest gibt keinen Grund zur Sorge:

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      1092         -
# 2  Extended offline    Completed without error       00%       924         -
# 3  Extended offline    Completed without error       00%       756         -
# 4  Extended offline    Completed without error       00%       588         -
# 5  Extended offline    Completed without error       00%       420         -
# 6  Extended offline    Completed without error       00%       252         -
# 7  Extended offline    Completed without error       00%        84         -
# 8  Extended offline    Completed without error       00%         0         -

SanDisk SDSSDP064G

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0002   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0002   100   100   000    Old_age   Always       -       1291
 12 Power_Cycle_Count       0x0002   100   100   000    Old_age   Always       -       17
165 Total_Write/Erase_Count 0x0002   100   100   000    Old_age   Always       -       31486
171 Program_Fail_Count      0x0002   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0002   100   100   000    Old_age   Always       -       0
173 Avg_Write/Erase_Count   0x0002   100   100   000    Old_age   Always       -       7
174 Unexpect_Power_Loss_Ct  0x0002   100   100   000    Old_age   Always       -       12
187 Reported_Uncorrect      0x0002   100   100   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0022   073   027   000    Old_age   Always       -       27 (Min/Max 18/43)
230 Perc_Write/Erase_Count  0x0002   100   100   000    Old_age   Always       -       23
232 Perc_Avail_Resrvd_Space 0x0003   100   100   005    Pre-fail  Always       -       0
234 Perc_Write/Erase_Ct_BC  0x0002   100   100   000    Old_age   Always       -       375
241 Total_LBAs_Written      0x0002   100   100   000    Old_age   Always       -       3807393811
242 Total_LBAs_Read         0x0002   100   100   000    Old_age   Always       -       2487113948

Auch hier scheint es laut dem SMART-Selbsttest keine Probleme zu geben:

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      1261         -
# 2  Extended offline    Completed without error       00%      1242         -

Ob Firmware-Aktualisierungen verfügbar sind, weiß ich nicht. Bei SanDisk finde ich nichts dazu und TeamGroup bietet ein 84MB fettes Update Tool für Windows an - kein Kommentar.

Hat jemand ähnliche Erfahrungen gemacht? Vielleicht war es ja auch nur Zufall, dass beide Laufwerke relativ zeitnah aus den Arrays sprangen.

MfG Jimini

 

[Knogle]

Und wo sind jetzt die Probleme?

Ich denke es liegt eher daran, dass sich der Controller einer der SSDs wohl verabschiedet..
Oder die Karte selber

Ich nutze ungerne solche Karten, dann eher hochwertige von LSI und SUN

 

[norse]

Kann es sein, das den SSDs eifnach die RAID befehle fehlen? So ist es bei den Consumer HDDs und dementsprechend werden die gerne mal aus RAIDs geworfen ohne Grund

 

[Icedaft]

Davon mal abgesehen, das sich mit der Sinn des ganzen (RAID mit SSDs) entzieht. Was bezweckst Du damit?

 

[Jimini]

Und wo sind jetzt die Probleme?

Na, zumindest für mich ist ein nicht vollständiges Array durchaus ein Problem

Ich denke es liegt eher daran, dass sich der Controller einer der SSDs wohl verabschiedet..
Oder die Karte selber

Ansonsten gibt es halt keinerlei Fehler, bisher kannte ich das so, dass sich ein sterbendes Laufwerk durch mehr oder weniger regelmäßige Kernelmeldungen bemerkbar macht.

Kann es sein, das den SSDs eifnach die RAID befehle fehlen? So ist es bei den Consumer HDDs und dementsprechend werden die gerne mal aus RAIDs geworfen ohne Grund

Hmmm, meines Wissens gibt es da keine "RAID-Befehle", sondern es sind bei normalen Laufwerken eher die Fehlertoleranzen. Ein Consumer-Laufwerk gibt schneller mal einen Fehler an das Betriebssystem weiter, wenn es irgendwo kurz hakt, woraufhin es dann auch schneller aus einem Array geworfen werden kann. Bei Laufwerken, welche explizit für den RAID-Betrieb zertifiziert sind, sind die Toleranzen etwas höher, so dass das Laufwerk nicht so schnell den Betrieb stört, wenn es kurz irgendwo klemmt.

Davon mal abgesehen, das sich mit der Sinn des ganzen (RAID mit SSDs) entzieht. Was bezweckst Du damit?

Auf dem RAID1 liegt das Betriebssystem. Da das System permanent läuft, will ich darüber die Wahrscheinlichkeit verringern, dass das System plötzlich wegen einer defekten SSD aussteigt. Da wirklich praktische Backups des Betriebssystems nur mit Images möglich sind und ich als Dateisystem etc4 einsetze, müsste ich die Kiste regelmäßig zum Backuppen runterfahren, was ich aber nicht möchte. Daher will ich ein kleines Mehr an Sicherheit durch die Spiegelung erreichen.

Mit Festplatten ist mir sowas bisher noch nicht passiert, aber es kann natürlich auch einfach Zufall sein. Ich hoffe nur inständig, dass der nächste Ausfall nicht innerhalb kurzer Zeit einen zweiten nach sich zieht - meistens ist man ja genau dann im Urlaub oder sonst irgendwie verhindert
Ich war mir nur unsicher, ob die Firmware von SSD da vielleicht irgendwelche störenden Eigenarten hat.

MfG Jimini

 

[RealMadnex]

Hmmm, meines Wissens gibt es da keine "RAID-Befehle", sondern es sind bei normalen Laufwerken eher die Fehlertoleranzen. Ein Consumer-Laufwerk gibt schneller mal einen Fehler an das Betriebssystem weiter, wenn es irgendwo kurz hakt, woraufhin es dann auch schneller aus einem Array geworfen werden kann. Bei Laufwerken, welche explizit für den RAID-Betrieb zertifiziert sind, sind die Toleranzen etwas höher, so dass das Laufwerk nicht so schnell den Betrieb stört, wenn es kurz irgendwo klemmt.

Es ist genau andersherum. Auf RAID optimierte HDDs melden beispielsweise Lesefehler recht zügig dem Betriebssystem bzw. dem RAID-Controller um das System nicht zu blockieren. Die benötigten Daten sind ja redundant vorhanden und können einfach von einem anderen Ort geholt oder errechnet werden. Consumer-Laufwerke gehen davon aus, dass die Daten nur ein Mal vorhanden sind und setzen unter Umständen alles daran sie lesen zu können, was den Rechner auch mal stilllegen kann. Merkt ein RAID-Controller das (die Toleranzzeit liegt gewöhnlich bei 7 Sekunden), wird die entsprechende HDD kurzerhand aus dem Array geworfen.

Was dein eigentliches Problem betrifft. Ich könnte mir vorstellen, dass wieder mal ein Kompatibilitätsproblem zwischen einer SSD und Linux besteht. So wie es bei den weit verbreiteten SSDs von Samsung und teilweise von Crucial der Fall ist bzw. war. Bei SSDs mit geringerer Verbreitung fallen solche Probleme seltener auf und werden auch seltener behoben. Aber das ist nur reine Spekulation.

 

[Jimini]

Es ist genau andersherum. Auf RAID optimierte HDDs melden beispielsweise Lesefehler recht zügig dem Betriebssystem bzw. dem RAID-Controller um das System nicht zu blockieren. Die benötigten Daten sind ja redundant vorhanden und können einfach von einem anderen Ort geholt oder errechnet werden. Consumer-Laufwerke gehen davon aus, dass die Daten nur ein Mal vorhanden sind und setzen unter Umständen alles daran sie lesen zu können, was den Rechner auch mal stilllegen kann. Merkt ein RAID-Controller das (die Toleranzzeit liegt gewöhnlich bei 7 Sekunden), wird die entsprechende HDD kurzerhand aus dem Array geworfen.

Stimmt. Danke für die Richtigstellung

Was dein eigentliches Problem betrifft. Ich könnte mir vorstellen, dass wieder mal ein Kompatibilitätsproblem zwischen einer SSD und Linux besteht. So wie es bei den weit verbreiteten SSDs von Samsung und teilweise von Crucial der Fall ist bzw. war. Bei SSDs mit geringerer Verbreitung fallen solche Probleme seltener auf und werden auch seltener behoben. Aber das ist nur reine Spekulation.

Zumindest SanDisk-SSD dieses Typs laufen bei mir eigentlich seit geraumer Zeit sauber und ohne Probleme. Aber das schließt die Hypothese natürlich nicht aus.

MfG Jimini

 

[Icedaft]

Vielleicht mal einen anderen Controller Dawicontrol DC-624e RAID retail, low profile, PCIe 2.0 x2 Preisvergleich | Geizhals Deutschland und andere (hochwertigere) SSDs Samsung SSD 850 PRO 128GB, SATA (MZ-7KE128BW) Preisvergleich | Geizhals Deutschland probieren, wenn Datensicherheit für Dich an erster Stelle steht?

 

[Jimini]

Vielleicht mal einen anderen Controller Dawicontrol DC-624e RAID retail, low profile, PCIe 2.0 x2 Preisvergleich | Geizhals Deutschland und andere (hochwertigere) SSDs Samsung SSD 850 PRO 128GB, SATA (MZ-7KE128BW) Preisvergleich | Geizhals Deutschland probieren, wenn Datensicherheit für Dich an erster Stelle steht?

Datensicherheit ist für mich zwar ohne Frage wichtig, allerdings wären mir >200€ nur für das RAID1 definitiv zu viel. Ich werde am Wochenende nochmal Images der beiden Laufwerke anlegen und dann schauen, wie sich das Konstrukt weiter verhält. Für den Ernstfall habe ich noch mehrere Festplatten hier, auf welche ich die Images ziehen könnte, wenn eins (oder beide) SSD wirklich die Biege machen sollten.
Dennoch vielen Dank für die Hinweise!

MfG Jimini

 

[Jimini]

Mir fiel gerade wieder ein, dass das System ab und an folgendes loggt:

kernel: ata8: illegal qc_active transition (0000003e->ffffffff)
kernel: ata8.00: exception Emask 0x2 SAct 0x3e SErr 0x0 action 0x6 frozen
kernel: ata8.00: failed command: READ FPDMA QUEUED
kernel: ata8.00: cmd 60/18:08:48:c3:dc/00:00:00:00:00/40 tag 1 ncq 12288 in
kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation)
kernel: ata8.00: status: { DRDY }
kernel: ata8.00: failed command: READ FPDMA QUEUED
kernel: ata8.00: cmd 60/38:10:08:c4:dc/00:00:00:00:00/40 tag 2 ncq 28672 in
kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation)
kernel: ata8.00: status: { DRDY }
kernel: ata8.00: failed command: READ FPDMA QUEUED
kernel: ata8.00: cmd 60/10:18:d0:bb:dc/00:00:00:00:00/40 tag 3 ncq 8192 in
kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation)
kernel: ata8.00: status: { DRDY }
kernel: ata8.00: failed command: READ FPDMA QUEUED
kernel: ata8.00: cmd 60/10:20:58:b9:dc/00:00:00:00:00/40 tag 4 ncq 8192 in
kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation)
kernel: ata8.00: status: { DRDY }
kernel: ata8.00: failed command: READ FPDMA QUEUED
kernel: ata8.00: cmd 60/10:28:18:af:dc/00:00:00:00:00/40 tag 5 ncq 8192 in
kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation)
kernel: ata8.00: status: { DRDY }
kernel: ata8: hard resetting link
kernel: ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
kernel ata8.00: configured for UDMA/133
kernel: ata8: EH complete

Ich muss mal in Erfahrung bringen, welches Laufwerk an diesem Port hängt - eventuell liegt das Problem ja hier.

MfG Jimni