SMART error (ErrorCount) detected auf Laptop-SSD

[wanne]

Ich kann mir auch nicht vorstellen, daß auf riesigen Datenvolumes (ab 100TB) die Prüfsummen des kompletten Datenbestands regelmässig berechnet und verglichen werden. Bei 100TB würde das selbst auf superschnellen SSDs locker einen Tag dauern, bei Festplatten mehrere Monate.

Es gibt aber keine 100TB große SSD. Du musst bedenken, dass Du ja auf 90HDDs auch 90 mal so schnell ließt. Es macht also wenig aus ob du eine oder 90 Platten scrubbst. Oder umgekehrt halt immer eine im Hintergrund scrubben kann während der Rest weiter mit voller Performance läuft. Wir testen in vielen Fällen tatsächlich alle 3 Monate.

[heisenberg]

Ich kann mir auch nicht vorstellen, daß auf riesigen Datenvolumes (ab 100TB) die Prüfsummen des kompletten Datenbestands regelmässig berechnet und verglichen werden. Bei 100TB würde das selbst auf superschnellen SSDs locker einen Tag dauern, bei Festplatten mehrere Monate.

Zusätzlich zu dem, was wanne bereits schrieb:

Deine Rechnung kann ich nicht so ganz nachvollziehen. Wenn ich mal als lineare Lesegeschwindigkeit einer Einzelfestplatte - langsamerweise - 150 MB/s annehme, dann dauert das bei 100 TB recht genau 8 Tage.

Dann haben wir da noch die Tatsache, dass ein Scrub vermutlich eher noch deutlich langsamer ist als lineare Lesegeschwindigkeit bei gleichzeitiger Produktivnutzung. Aber nicht mehrere Monate statt 8 Tagen. Bei 3T 10T komprimiert belegt( 6,7T physisch belegt) von einem RAID10(ZFS) mit 4 Platten dauert der Scrub bei mir derzeit 12 Stunden.

[MSfree]

Es gibt aber keine 100TB große SSD.

Daß man solche Volumegrößen nur mit SSD/HDD-Arrays bekommt, sollte klar sein.

Es macht also wenig aus ob du eine oder 90 Platten scrubbst.

Trotzdem dauert das bei einer 20TB-Platte fast 2 Tage. In der Zeit geht aber die Performance des Diskarrays in den Keller. Mein kleines, privates 4-Platten RAID-5 rödelt auch einmal im Monat los und macht einen Konsistenzcheck. Der dauert 22h und das Tagesbackup, das dort drauf landet, dauert 2h statt der üblichen 20min.

Oder umgekehrt halt immer eine im Hintergrund scrubben kann während der Rest weiter mit voller Performance läuft. Wir testen in vielen Fällen tatsächlich alle 3 Monate.

Ich weiß nicht, wie das mit ZFS aussieht, bei meinem RAID-5 läuft gar nichts mit voller Geschwindigkeit weiter, während der Konsistenzcheck läuft. In meinem Fall stört mich das nicht. Bei einem viel beschäftigten Server düften die Anwender wenig begeistert sein.

[MSfree]

Deine Rechnung kann ich nicht so ganz nachvollziehen. Wenn ich mal als lineare Lesegeschwindigkeit einer Einzelfestplatte - langsamerweise - 150 MB/s annehme, dann dauert das bei 100 TB recht genau 8 Tage.

Ja Sorry, ich hatte da wohl 'nen Faktor 10 Fehler drin.

[heisenberg]

Trotzdem dauert das bei einer 20TB-Platte fast 2 Tage. In der Zeit geht aber die Performance des Diskarrays in den Keller. Mein kleines, privates 4-Platten RAID-5 rödelt auch einmal im Monat los und macht einen Konsistenzcheck. Der dauert 22h und das Tagesbackup, das dort drauf landet, dauert 2h statt der üblichen 20min.

Das ist tatsächlich ein guter Punkt. Ich habe noch eine recht alte Schrottkiste am laufen. (QEMU-VMs mit geringer Wichtigkeit). Die I/O-Performance ist da recht begrenzt. Wenn ich da einen Scrub mache und das ohne diesen zusätzlich zu begrenzen - da gibt's bei ZFS 1-2 Einstellungen dazu - dann sind mir da tatsächlich VMs abgestürzt, weil da dann wohl irgendwelche Timeouts zu hoch waren. Bei dem Backupserver bei mir ist das ziehmlich unkritisch.

[wanne]

In der Zeit geht aber die Performance des Diskarrays in den Keller. Mein kleines, privates 4-Platten RAID-5 rödelt auch einmal im Monat los und macht einen Konsistenzcheck. Der dauert 22h und das Tagesbackup, das dort drauf landet, dauert 2h statt der üblichen 20min.

Das ist der Grund warum im professionellen Bereich kaum RAID-5 eingesetzt wird sondern fast immer RAID-10.

da gibt's bei ZFS 1-2 Einstellungen dazu

Und erfahrungsgemäß hast du recht: Egal was die Dokumentation sagt: Die Performance von ZFS geht in den Keller wenn man scrubt.
Hier mal ein Beispiel wie das läuft: Quobyte (vormals XtreemFS ) läuft verteilt über 20 Server á 90 Platten und hält immer 3 Kopien vor. Wenn du jetzt gerade eine platte scrubbst ließt der einfach von ner anderen Kopie die in den aller meisten Fällen sogar auf einem völlig anderen Server liegt. Theoretisch sollte entsprechend die Performance nicht beeinflusst werden. Real gehen die Latenzen (die sowieso schon ein paar Größenordnungen über denen von einem nativen ZFS liegen) weiter hoch. Sowas nutzt du üblicherweise nicht als root-Dateisystem aber wohl für Daten auf denen wirklich gerechnet wird. Gibst du deiner Kiste halt genug RAM, dass ordentlich gecached wird. Bis jetzt ist es mir noch praktisch nie vorgekommen, dass Quobyte da Inkonsistenzen gefunden hat. Das liegt aber eben daran, dass die Platte ausgetauscht wird, wenn sie beim Scrub CRC Fehler liefert bevor sie ausgetauscht werden kann. Deswegen meine ich. Wer auf die SMART-Werte achtet weiß ob seine Platte eventuell Daten verliert oder nicht.

[ingo2]

Ich werfe hier noch mal einen anderen Punkt zu dem Thema auf, denn eine echte Lösung gibt's ja bisher nicht.

Ich habe hier bei meinem Alder Lake PC mit einer nagelneuen Samsung 980 NVMe-SSD folgendes Problem beobachtet: Hatte auch ab und zu mal Hänger des Systems, der sichtbare Teil davon war ein rapider Anstieg der Temperaturwarnungen der SSD in den SMART-Werten. Sogar "sensors" hat öfter hohe Temperatutspitzen der SSD reportet, obwohl praktisch minimale Daten-Aktivität herrschte.

Letztendlich als eine Ursache hat sich APST der SSD herausgestellt wobei die SSD unabhängig vom Betriebssystem ihre Power-States wechselt. Es gibt dazu einen informativen Kernel Bug-Report:
https://bugzilla.kernel.org/show_bug.cgi?id=195039 im "Comment 105".

Ich habe dann APST zunächst komplett abgeschaltet mit dem Kernel-Parameter

Code: Alles auswählen

nvme_core.default_ps_max_latency_us=0

und siehe da, der Spuk war weg. Habe dann weiter mit den Zeiten gespielt und festgestellt dass bei mir beide Power-States "3" und "4" Probleme machen und nur die dann komplett deaktiviert. Jetzt habe ich 1350µs eingetragen und alles ist ok. Eine dadurch erhöhte Leistungsaufnahme konnte ich nicht messen/nachweisen. Die wahre Ursache dafür ist weiterhin unklar, da streiten sich Betriebssystem, Firmware der SSD und BIOS des Mainboards. jedenfalls gibt's für einige SSD-Typen schon "Quirks" im Kernel.

Ist ja ein schneller Test - probier's einfach mal,

Ingo