Hallo zusammen,
meine DS411+ mit 4xWD20EARS läuft seit Jahren anstandslos. Backups werden mit großer Sorgfalt auf via eSATA angebundenen Disks gemacht und diese auch mind. 1 x im Jahr per vollständigen auslesen, beschreiben mit Zufallszahlen und SMART Tests auf Herz und Nieren geprüft.
Eigentlich bin ich bis heute davon ausgegangen, dass so ein Pflegeprogramm für die internen Platten nicht zwingend notwendig ist, weil diese ja regelmäßig laufen, die Daten per RAID 5 abgesichert sind und die SMART Werte auch überwacht werden. Letztens bin ich dann doch ins Überlegen gekommen, was mit Daten mit der Zeit geschieht, auf die nie zugegriffen wird?
Nach ausprobieren des nicht ohne Probleme verlaufenen Data Scrubbings und diversen Recherchen habe ich meine Meinung grundlegend geändert. Ansonsten hätte ich bei einem zukünftig anstehenden Rebuild vermutlich ein Problem gehabt.
Bei der Thematik sind mir bei näherer Betrachtung doch einige Fragen und Unstimmigkeiten aufgekommen, weswegen ich mich an Euch wende.
Nach Leseproblemen auf einer Platte merkt die Firmware sich diese als pending und der Sektor wird beim nächsten Schreibzugriff reallocated. Je Noch Modell nicht generell sondern erst dann wenn der verify fehl schlägt.
Hat die Fehlerkorrektur der Platte keine Chance so meldet sie zusätzlich einen Lesefehler ans OS (soft read error).
In einem Linux RAID (md) ist dieser Level dafür zuständig die Daten, weil sie ja durch die Redundanz der anderen Platten noch vorhanden sind, einfach noch mal zu schreiben, damit die Plattenfirmware handeln kann und alles ist wieder gut.
Jetzt zu meinen Fragen:
Was passiert mit schlechten Sektoren, die die Platte nach Korrekturversuchen der Firmware (Unabhängig von TLER) doch noch lesen konnte? Bekommt davon das OS/Kernel was mit und wird etwas unternommen?
Scrubbing wird normalerweise von md durchgeführt und z.B. per mdadm Befehl gestartet. Auch bei Synology? Oder macht das hier ein Stück Software von Syno? Wäre ein generelles Neuschreiben der Daten nicht angebracht um den ersten Fragenblock oben zu erschlagen?
Festgestellt habe ich:
Würde bedeuten das bei normalen Betrieb nichts unternommen würde? In vielen anderen Forenbeiträgen findet man auch Hinweise, dass beim Boot der DS in /var/log/messages zu erkennen ist, dass auf allen Platten auto_remap aktiviert wird. Bei mir nicht. Ist das normal? Oder übernimmt das Korrigieren im normalen Betrieb bei Synology evtl. auch Zusatzsoftware und nicht md?
Hier ein paar Zeilen aus dem /var/log/messages während des Scrubbings:
Das sieht für mich so aus, als ob sich doch der Kernel (md) um das Korrigieren kümmert?
Bitte um Infos was Ihr dazu alles wisst um Licht ins dunkle zu bringen. Im Internet findet man viel Einzeldetails aber es schwer abzuschätzen wie es in Gänze z.B. bei einer DS funktioniert.
Wie sieht es bei einem erweiterten SMART Test aus wenn dabei Sektoren markiert werden? Reagiert da wer darauf? Wenn nicht, dann bringt ein regelmäßiger erweiterter Test auch nichts.
Leider habe ich anscheinend mit SMART Probleme, die ich gerade noch untersuche und einen eigenen Thread dazu aufmachen werde. Test hängt bei 90% und smartctl Kommandos auf der Konsole zeigen alle, dass kein SMART aktiv ist, obwohl die Web-Oberfläche alles anzeigt.
Auf jeden Fall bin ich jetzt davon überzeugt, dass ein RAID 5 auch regelmäßiges Scrubbing benötigt. Sonst droht bei einem späteren evtl. mal notwendigen Rebuild Datenverlust, weil dann weitere Lesefehler auf anderen Platten noch hinzukommen und das wäre es dann. Oder RAID 6.
Viele Grüße
Christian
meine DS411+ mit 4xWD20EARS läuft seit Jahren anstandslos. Backups werden mit großer Sorgfalt auf via eSATA angebundenen Disks gemacht und diese auch mind. 1 x im Jahr per vollständigen auslesen, beschreiben mit Zufallszahlen und SMART Tests auf Herz und Nieren geprüft.
Eigentlich bin ich bis heute davon ausgegangen, dass so ein Pflegeprogramm für die internen Platten nicht zwingend notwendig ist, weil diese ja regelmäßig laufen, die Daten per RAID 5 abgesichert sind und die SMART Werte auch überwacht werden. Letztens bin ich dann doch ins Überlegen gekommen, was mit Daten mit der Zeit geschieht, auf die nie zugegriffen wird?
Nach ausprobieren des nicht ohne Probleme verlaufenen Data Scrubbings und diversen Recherchen habe ich meine Meinung grundlegend geändert. Ansonsten hätte ich bei einem zukünftig anstehenden Rebuild vermutlich ein Problem gehabt.
Bei der Thematik sind mir bei näherer Betrachtung doch einige Fragen und Unstimmigkeiten aufgekommen, weswegen ich mich an Euch wende.
Nach Leseproblemen auf einer Platte merkt die Firmware sich diese als pending und der Sektor wird beim nächsten Schreibzugriff reallocated. Je Noch Modell nicht generell sondern erst dann wenn der verify fehl schlägt.
Hat die Fehlerkorrektur der Platte keine Chance so meldet sie zusätzlich einen Lesefehler ans OS (soft read error).
In einem Linux RAID (md) ist dieser Level dafür zuständig die Daten, weil sie ja durch die Redundanz der anderen Platten noch vorhanden sind, einfach noch mal zu schreiben, damit die Plattenfirmware handeln kann und alles ist wieder gut.
Jetzt zu meinen Fragen:
Was passiert mit schlechten Sektoren, die die Platte nach Korrekturversuchen der Firmware (Unabhängig von TLER) doch noch lesen konnte? Bekommt davon das OS/Kernel was mit und wird etwas unternommen?
Scrubbing wird normalerweise von md durchgeführt und z.B. per mdadm Befehl gestartet. Auch bei Synology? Oder macht das hier ein Stück Software von Syno? Wäre ein generelles Neuschreiben der Daten nicht angebracht um den ersten Fragenblock oben zu erschlagen?
Festgestellt habe ich:
Rich (BBCode):
nas> cat /sys/block/md2/md/auto_remap
0Hier ein paar Zeilen aus dem /var/log/messages während des Scrubbings:
Rich (BBCode):
May 20 20:59:50 kernel: [91371.077825] ata2.00: device reported invalid CHS sector 0
May 20 20:59:50 kernel: [91431.776089] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
May 20 20:59:50 kernel: [91431.783149] ata2.00: failed command: READ DMA EXT
May 20 20:59:50 kernel: [91431.787865] ata2.00: cmd 25/00:00:b0:d6:85/00:04:e1:00:00/e0 tag 0 dma 524288 in
May 20 20:59:50 kernel: [91431.787868] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
May 20 20:59:50 kernel: [91431.802649] ata2.00: status: { DRDY }
...
May 20 20:59:50 kernel: [91555.139139] read error corrected, md2, sdb5 index [1], sector 3783645456 [raid5_end_read_request]
...
May 20 21:24:39 kernel: [93043.712100] ata3.00: exception Emask 0x0 SAct 0x187c000 SErr 0x0 action 0x6 frozen
May 20 21:24:39 kernel: [93043.719691] ata3.00: failed command: READ FPDMA QUEUED
May 20 21:24:39 kernel: [93043.724852] ata3.00: cmd 60/00:70:20:64:ca/04:00:e4:00:00/40 tag 14 ncq 524288 in
May 20 21:24:39 kernel: [93043.724856] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
May 20 21:24:39 kernel: [93043.739780] ata3.00: status: { DRDY }Bitte um Infos was Ihr dazu alles wisst um Licht ins dunkle zu bringen. Im Internet findet man viel Einzeldetails aber es schwer abzuschätzen wie es in Gänze z.B. bei einer DS funktioniert.
Wie sieht es bei einem erweiterten SMART Test aus wenn dabei Sektoren markiert werden? Reagiert da wer darauf? Wenn nicht, dann bringt ein regelmäßiger erweiterter Test auch nichts.
Leider habe ich anscheinend mit SMART Probleme, die ich gerade noch untersuche und einen eigenen Thread dazu aufmachen werde. Test hängt bei 90% und smartctl Kommandos auf der Konsole zeigen alle, dass kein SMART aktiv ist, obwohl die Web-Oberfläche alles anzeigt.
Auf jeden Fall bin ich jetzt davon überzeugt, dass ein RAID 5 auch regelmäßiges Scrubbing benötigt. Sonst droht bei einem späteren evtl. mal notwendigen Rebuild Datenverlust, weil dann weitere Lesefehler auf anderen Platten noch hinzukommen und das wäre es dann. Oder RAID 6.
Viele Grüße
Christian
Zuletzt bearbeitet:
