WD RED 8TB im RAID mit Pending/uncorrectable Sectors

[Shagnar]

Hallo,

ich habe zwei RAID5 bestehend aus jeweils 5 WD RED mit 8TB. (4+1 Parity, also 29TiB formatierte Nettokapazität)

Eines ist das Haupt-System für mein Nas/nextcloud/dlna/..., das andere ist das Backup-System, wohin jede Nacht gesichert wird. (Außerdem gibt es für wichtige Daten von ca. 3 TB ein weiteres, örtlich getrenntes Backup)

Host OS: Debian, Dateisystem ext4, es handelt sich jeweils um ganz normale Desktop-Systeme (also keine Server-Hardware o.Ä.)

Ich habe das Problem, dass auf meinem Haupt-System eine der Platten 16 current_pending_sectors und 8 offline_uncorrectable hat. Zum Glück immerhin keine Lesefehler (raw_read_error rate 0).

madm hat damit offenbar keine Probleme, RAID state ist clean und alle Platten sind im Status active sync

1. Frage: Ist das schon ein Zeitpunkt an dem ich mir ernsthafte Sorgen um die Platte machen sollte? Die Anzahl der Fehler ist seit zwei Wochen konstant (davor in 2-3 Schüben angestiegen)

Da die Platten immernoch relativ teuer sind und ich mich inzwischen auch nicht mehr für die 8er entscheiden würde (laut, warm, stromverbrauch) möchte ich ungern eine nachkaufen. eine 10er einsetzen wäre noch teurer und würde vor allem den schönen Plattenplatz verschwenden.

Mein Plan war jetzt folgender: Ich nutze aktuell nur ca 22TiB der 29 und habe noch ziemlich viel "Müll" drauf, den ich löschen könnte. Wenn ich das Raid5 nun aus 3+1 Platte aufbauen würde, könnte ich die angeschlagene Platte aus dem Verbund nehmen, hätte knapp 22TiB nutzbare Kapazität und als netten Nebeneffekt noch eine Spare-Platte, da ich auf dem Backup-System entsprechend auch nur 3+1 Platten bräuchte.

2. Frage: Ergibt meine Überlegung soweit Sinn?

Falls ja: Da das Dateisystem (ext4) so groß ist, dass resize2fs damit nicht mehr klarkommt bleibt mir meines Wissens nichts anderes übrig, als beide RAIDs mit der reduzierten Anzahl an Platten neu aufzubauen und die Daten langwierig wieder zurückzukopieren. Ich reduziere in der Zeit leider von einem (bzw. zwei für die wichtigen Daten) auf kein (bzw. eines für die wichtigen Daten) Backup. Lässt sich das irgendwie intelligenter Lösen oder habt ihr sonstige Tipps für das Unterfangen um das Risiko eines Datenverlustes möglichst gering zu halten?

 

[Trambahner]

Wenn das Filesystem so groß wird und eh neu aufgebaut werden soll, dann würde ich gleich zu ZFS raten.
Wenn das in mehreren Schüben passiert ist, ja, dann würde ich mir Sorgen machen.

Btw, bei Multi-Terrabyte-Raids mit nur 1 Redundanzplatte zu arbeiten (also Raid5 bzw. Raidz1), halte ich für fahrlässig. Die Rebuildzeiten nach einem HDD-Ausfall können je nach Filesystem und Belegung so lang sein, dass währenddessen einer weitere HDD eingeht.

 

[Side2005]

Wenn das Filesystem so groß wird und eh neu aufgebaut werden soll, dann würde ich gleich zu ZFS raten.

Kann ich nur zustimmen. In Verbindung mit sanoid/syncoid eine extrem ausfallsichere und flexible Angelegenheit. Verwende es privat und ist auf allen Systemen bei uns auf der Arbeit eingerichtet (also Kombi zfs+sanoid). Kindereinfache Konfiguration von Retentionpolicies pro Dataset inkl. Vererbung, Replikation auf lokal -oder remotedateisysteme. Kanns jedem empfehlen.

Btw, bei Multi-Terrabyte-Raids mit nur 1 Redundanzplatte zu arbeiten (also Raid5 bzw. Raidz1), halte ich für fahrlässig. Die Rebuildzeiten nach einem HDD-Ausfall können je nach Filesystem und Belegung so lang sein, dass währenddessen einer weitere HDD eingeht.

Kann ich auch nur zustimmen. Würde sagen 4TBx3 Raid5/Raidz1 ist die absolute Obergrenze. Alles darüber ist Datenselbstmord.

1. Frage: Ist das schon ein Zeitpunkt an dem ich mir ernsthafte Sorgen um die Platte machen sollte? Die Anzahl der Fehler ist seit zwei Wochen konstant (davor in 2-3 Schüben angestiegen)

Für mich gilt: wenn das RAID entsprechend dimensioniert ist (s. oben) und man einen Backupplan hat, dann tausche ich Festplatten erst, wenn sie wirklich den Geist aufgeben (also wenn zfs die Festplatte als failed markiert hat).

 

[Holt]

ich habe zwei RAID5 bestehend aus jeweils 5 WD RED mit 8TB. (4+1 Parity, also 29TB formatierte Nettokapazität)

Nein, es sind 32TB bzw. 29TiB, Windows verwendet eben diesen Dezimal-Präfix (die im Internationalen Einheitensystem (SI) definiert sind) als Einheit, rechnet aber mit Binärpräfixe, also auf Basis von Zweierpotenzen und müsste daher korrekterweise TiB als Einheit für Tebibyte verwendet werden, macht es aber nicht.

Ich habe das Problem, dass auf meinem Haupt-System eine der Platten 16 current_pending_sectors und 8 offline_uncorrectable hat. Zum Glück immerhin keine Lesefehler (raw_read_error rate 0).

madm hat damit offenbar keine Probleme, RAID state ist clean und alle Platten sind im Status active sync

Eigentlich sollten Platten im RAID keine schwebenden Sektoren haben, denn Schwebende Sektoren sind einfach nur Sektoren deren Daten nicht mehr zur ECC passen die hinter jedem Sektor steht und die mit deren Hilfe auch nicht mehr korrigiert werden können. Da die korrekten Daten nicht mehr feststellbar sind, gibt die Platte statt falscher Daten einen Lesefehler als Antwort wenn man versucht diese schwebenden Sektoren zu lesen. Das kann auch anderen Gründe als defekte Oberflächen haben, z.B. einen Stromausfall während eines Schreibvorgang der dazu führt, dass eben nicht die ganze Daten plus der neuen ECC geschrieben wurden oder wegen eines Stoßes oder Vibrationen ist der Kopf beim Schreiben aus der Spur gekommen und hat Daten auf der Nachbarspur überschrieben. Auch arbeiten HDDs nicht 100%ig und die Hersteller geben die Fehlerhäufigkeit auch in Form der UBER an, wobei eine UBER von 1:10^14 bedeutet, dass je 10^14 gelesener Bits was etwa 12TB gelesener Daten entspricht, ein Lesefehler und damit schwebender Sektor im Rahmen der Erwartungen liegt.

Die Controller merken sich die schwebenden Sektoren und prüfen die Daten nach dem erneuten Schreiben auf diese Sektoren, dann verschwinden diese einfach oder werden eben durch Reservesektoren ersetzt.

HDDs in einem echten RAID, also einem mit Redundanz und nicht einem RAID 0 welches eigentlich ein AID 0 ist, zeigen daher normalerweise keine schwebenden Sektoren, weil die RAID Controller (ggf. RAID SW) bei Lesefehlern die Daten aus den Daten der anderen Platten rekonstruiert und den Sektor überschreibt bei denen der Lesefehler aufgetreten ist. Keine Ahnung wieso dies hier nicht geklappt hat, aber hast Du mal ein Scrubbing versucht?

1. Frage: Ist das schon ein Zeitpunkt an dem ich mir ernsthafte Sorgen um die Platte machen sollte? Die Anzahl der Fehler ist seit zwei Wochen konstant (davor in 2-3 Schüben angestiegen)

Gegen Sorgen helfen Backups und Du solltest Dir eher Sorgen machen wieso das Überschreiben dieser schwebenden Sektoren nicht geklappt hat.

Da die Platten immernoch relativ teuer sind und ich mich inzwischen auch nicht mehr für die 8er entscheiden würde (laut, warm, stromverbrauch)

Hast Du denn nicht die mit Helium gefüllten?

Da das Dateisystem (ext4) so groß ist, dass resize2fs damit nicht mehr klarkommt bleibt mir meines Wissens nichts anderes übrig, als beide RAIDs mit der reduzierten Anzahl an Platten neu aufzubauen und die Daten langwierig wieder zurückzukopieren.

md RAID können Growing, aber ich weiß nicht ob das auch in die andere Richtung geht, also Entfernen statt Zufügen von Platten.

Wenn das Filesystem so groß wird und eh neu aufgebaut werden soll, dann würde ich gleich zu ZFS raten.

Wieso? Nur weil Du immer dazu rätst?

Btw, bei Multi-Terrabyte-Raids mit nur 1 Redundanzplatte zu arbeiten (also Raid5 bzw. Raidz1), halte ich für fahrlässig. Die Rebuildzeiten nach einem HDD-Ausfall können je nach Filesystem und Belegung so lang sein, dass währenddessen einer weitere HDD eingeht.

Dies wäre hier noch nicht einmal das Hauptproblem, sondern die UBER, denn die Red haben nur eine UBER von 1:10^14 und damit ist die theoretische Chance auf ein erfolgreiches Rebuild des RAID 5 aus 5x8TB nur etwa 1,2, wären es HDDs mit einer UBER von 1:10^15 wie die IronWolf 8TB sie haben, wären es über 75%!

 

[Shagnar]

danke euch dreien.

Ich hab nunmal die 8TB Platten und würde diese gerne weiter verwenden. Wäre ein Raid 6 mit 4+2 (bzw. bei Umstieg auf zfs entsprechend Raidz2) noch genauso Datenselbstmord oder wäre hier das Gröbste erstmal aus der Welt geschafft? Falls nicht, was lässt sich sinnvoll sonst mit den vorhandenen Platten darstellen?

Nein, es sind 32TB bzw. 29TiB, Windows verwendet eben diesen Dezimal-Präfix (die im Internationalen Einheitensystem (SI) definiert sind) als Einheit, rechnet aber mit Binärpräfixe, also auf Basis von Zweierpotenzen und müsste daher korrekterweise TiB als Einheit für Tebibyte verwendet werden, macht es aber nicht.
Eigentlich sollten Platten im RAID keine schwebenden Sektoren haben, denn Schwebende Sektoren sind einfach nur Sektoren deren Daten nicht mehr zur ECC passen die hinter jedem Sektor steht und die mit deren Hilfe auch nicht mehr korrigiert werden können. Da die korrekten Daten nicht mehr feststellbar sind, gibt die Platte statt falscher Daten einen Lesefehler als Antwort wenn man versucht diese schwebenden Sektoren zu lesen. Das kann auch anderen Gründe als defekte Oberflächen haben, z.B. einen Stromausfall während eines Schreibvorgang der dazu führt, dass eben nicht die ganze Daten plus der neuen ECC geschrieben wurden oder wegen eines Stoßes oder Vibrationen ist der Kopf beim Schreiben aus der Spur gekommen und hat Daten auf der Nachbarspur überschrieben. Auch arbeiten HDDs nicht 100%ig und die Hersteller geben die Fehlerhäufigkeit auch in Form der UBER an, wobei eine UBER von 1:10^14 bedeutet, dass je 10^14 gelesener Bits was etwa 12TB gelesener Daten entspricht, ein Lesefehler und damit schwebender Sektor im Rahmen der Erwartungen liegt.

Die Controller merken sich die schwebenden Sektoren und prüfen die Daten nach dem erneuten Schreiben auf diese Sektoren, dann verschwinden diese einfach oder werden eben durch Reservesektoren ersetzt.

HDDs in einem echten RAID, also einem mit Redundanz und nicht einem RAID 0 welches eigentlich ein AID 0 ist, zeigen daher normalerweise keine schwebenden Sektoren, weil die RAID Controller (ggf. RAID SW) bei Lesefehlern die Daten aus den Daten der anderen Platten rekonstruiert und den Sektor überschreibt bei denen der Lesefehler aufgetreten ist. Keine Ahnung wieso dies hier nicht geklappt hat, aber hast Du mal ein Scrubbing versucht?

Gegen Sorgen helfen Backups und Du solltest Dir eher Sorgen machen wieso das Überschreiben dieser schwebenden Sektoren nicht geklappt hat.

Hast Du denn nicht die mit Helium gefüllten?

md RAID können Growing, aber ich weiß nicht ob das auch in die andere Richtung geht, also Entfernen statt Zufügen von Platten.

Wieso? Nur weil Du immer dazu rätst?
Dies wäre hier noch nicht einmal das Hauptproblem, sondern die UBER, denn die Red haben nur eine UBER von 1:10^14 und damit ist die theoretische Chance auf ein erfolgreiches Rebuild des RAID 5 aus 5x8TB nur etwa 1,2, wären es HDDs mit einer UBER von 1:10^15 wie die IronWolf 8TB sie haben, wären es über 75%!

Ich meinte natürlich 29 TiB, danke für den Hinweis. Es sind die mit Helium gefüllten, aber die 10er (und 12er) sind wensetlich sparsamer und leiser im idle.

Backup habe ich.

Ich habe mal ein check gestartet um zu sehen wie es sich mit den problematischen Sektoren verhält.

Du würdest also nicht zu zfs raten?

Ich sehe immer mehr, dass das Problem die großen Platten sind. Aber sind diese nicht gerade für meinen Einsatzzweck (NAS) konzipiert?

 

[Holt]

Wäre ein Raid 6 mit 4+2 (bzw. bei Umstieg auf zfs entsprechend Raidz2) noch genauso Datenselbstmord oder wäre hier das Gröbste erstmal aus der Welt geschafft?

Ein RAID 6 wäre mit diesem Platten deutlich sinnvoller als ein RAID 5.

Es sind die mit Helium gefüllten, aber die 10er (und 12er) sind wensetlich sparsamer und leiser im idle.

Da bin ich etwas skeptisch, denn die 2,8W im Idle die Geizhals für die WD100EFAX angibt, scheinen mir etwas unrealistisch. Leider habe ich keinen Review gefunden der dies genau nachgemessen hat. Bei Tweaktown wurde nur die Leistungsaufnahme unter Last ermittelt, die 1,5W unter der der alten Red 8TB lag und bei Aphnetworks nur die des ganzen NAS im Idle, wo die Leistungsaufnahme dann mit 10W um 1W unter der mit den alten Red 8TB oder der IronWolf 10TB lag. Dies ist weniger als die über 2,2W zwischen den 5W der IronWolf 10TB und den 2,8W die WD für die Red 10TB vermeldet.

Die alte Red 8TB WD80EFZX ist im Idle mit 5,2W angegeben, während die Purple 8TB WD80PURZ (beide mit Helium) mit 5,7W ein halbes Watt mehr hat, was an zusätzlicher Elektronik wie z.B. anderen / mehr Vibrationssensoren oder der FW (die diese ggf. im Idle deaktiviert) liegen kann. Die 10TB Purple WD100PURZ mit 5400rpm ist mit 5W im Idle angegeben, also 0,7W weniger als bei der 8TB und ich vermute die Red 10TB dürfte real eine Leistungsaufnahme von so 4,5W haben, was dann wieder ein halbes Watt unter der Purple wäre, die der Red ja extrem ähnlich ist. Die 2,8W sind vermutlich nur mit einer besonderen Energiespareinstellung zu erzielen und da ist die Frage ob das eigene System diese unterstützt und welche Nachteile (ähnlich wie damals der Grüne Tod der Green wegen zu vieler Load Unload Zyklen) damit ggf. verbunden sind.

Du würdest also nicht zu zfs raten?

Wenn man einen Rechner mit ECC RAM hat, kann man auch ZFS nehmen, aber ZFS ohne ECC RAM würde ich nicht nehmen und ZFS hat auch andere Nachteile, so kann es kein Growing durch hinzufügen von weiteren Platten, die werden da nur wie bei JOBD (BIG) angehängt, ohne den gleichen Schutz wie die Platten des RAIDs zu haben. Auch gibt es kein Tool um ein korruptes ZFS zu reparieren, wenn das mal korrupt ist, muss man es neu aufsetzen und das Backup zurückspielen.

 

[Side2005]

Wenn man einen Rechner mit ECC RAM hat, kann man auch ZFS nehmen, aber ZFS ohne ECC RAM würde ich nicht nehmen [...]

zfs hat die gleichen Nachteile ohne ECC RAM wie andere Dateisysteme ohne ECC RAM.
Der Fehler durch einen ungültigen Prüfsummenabgleich (obwohl die Prüfsumme eigentlich richtig ist) bei non-ECC ist kleiner als die Wahrscheinlichkeit eines Fehlers durch bitrot. (relativ zur Laufzeit von z.B. 10 Jahren)

ZFS hat auch andere Nachteile, so kann es kein Growing durch hinzufügen von weiteren Platten, die werden da nur wie bei JOBD (BIG) angehängt, ohne den gleichen Schutz wie die Platten des RAIDs zu haben.[...]

Falsch.
Folgende Annahme. Bestehender pool names "Tank", bestehend aus 3x4TB im raidz1.

zpool add Tank raidz1 /dev/disk/by-id/DEVA /dev/disk/by-id/DEVB /dev/disk/by-id/DEVC

und zack, hast du dein zpool um ein vdev (bestend aus 3x4TB raidz1) erweitert.

Das dem ganzen Regeln und Limits unterliegen - ist der Komplexität wegen natürlich klar. Aber der Ausfallschutz ist bei richtiger Handhabung immer gegeben.

Auch gibt es kein Tool um ein korruptes ZFS zu reparieren, wenn das mal korrupt ist, muss man es neu aufsetzen und das Backup zurückspielen.

Auch falsch.

zpool scrub tank
Das alle 2 Wochen per cron und fertig ist.
Darauf muss ich allerdings sagen ist auch wirklich nur Verlass, wenn ECC-RAM verwendet wird. Dann spielt zfs aber seine Möglichkeiten voll aus. Stichwort "immortal filesystem".

 

[Holt]

Side2005, da muss ich in allen Punkten widersprechen, habe aber keine Lust dies immer und immer wieder zu diskutieren, zumal gegen jemanden der keine Belege vorbringt, wenn er mir widerspricht. Möge der TE selbst entscheiden oder er ZFS will oder nicht.

 

[Shagnar]

check ist bei 20%, Current_Pending_Sector ist auf 0 runter bei weiterhin 8 Offline_Uncorrectable.

 

[Holt]

Die Offline_Uncorrectable werden oft erst beim nächsten Start der Platte aktualisiert, wenn sie vorher stromlos war. Lass Dich also davon nicht irritieren und schau wie der Wert ist, nachdem die Platten stromlos waren, also z.B. der Rechner neu gestartet wurde.

 

[Shagnar]

nachdem der check erfolgreich durchgelaufen ist (mismatch_cnt=0) habe ich den server herunter gefahren und nach einer minute neu gestartet. so sehen die smart daten jetzt aus:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   131   131   054    Pre-fail  Offline      -       116
  3 Spin_Up_Time            0x0007   152   152   024    Pre-fail  Always       -       456 (Average 411)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       21
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   128   128   020    Pre-fail  Offline      -       18
  9 Power_On_Hours          0x0012   097   097   000    Old_age   Always       -       22992
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       21
 22 Helium_Level            0x0023   100   100   025    Pre-fail  Always       -       100
192 Power-Off_Retract_Count 0x0032   094   094   000    Old_age   Always       -       7331
193 Load_Cycle_Count        0x0012   094   094   000    Old_age   Always       -       7331
194 Temperature_Celsius     0x0002   171   171   000    Old_age   Always       -       35 (Min/Max 18/50)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       8
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

es scheint, als hätte sich die Platte wieder gefangen, nachdem sie die 8 defekten Sektoren ausgemustert hat. Was meint ihr?

 

[Holt]

Sie hat keine Sektoren als defekt "ausgemustert", denn die hätte sie ja durch Reservesektoren ersetzen müssen und das hat sie nicht:
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0

Wieso die noch immer 8 Offline_Uncorrectable meldet, kann ich Dir nicht sagen, aber es gibt jetzt keine schwebenden Sektoren mehr.

 

[Side2005]

Side2005, da muss ich in allen Punkten widersprechen, habe aber keine Lust dies immer und immer wieder zu diskutieren, zumal gegen jemanden der keine Belege vorbringt, wenn er mir widerspricht. Möge der TE selbst entscheiden oder er ZFS will oder nicht.

Da ich meinen zweiten Punkt nicht weiter belegen muss und sich 1 und 3 in gewisser Weise überschneiden, genügt es, wenn du dir 15 Minuten Zeit nimmst um diesen Artikel zu verstehen

Will ZFS and non-ECC RAM kill your data?

Um Matthew Ahrens direkt zu zitieren:

There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

Und falls du dich wunderst wer dieser Herr Ahrens ist:
GitHub OpenZFS-Wiki


Grüße

 

[Holt]

Hast du von dem Mitentwickler was anderes erwartet? Das Zitat findet sich auch hier, mit folgendem Kommentar dazu:

File systems such as NTFS, EXT4, etc have (data recovery) tools that may allow you to rescue your files when things go bad due to bad memory. ZFS does not have such tools, if the pool is corrupt, all data must be considered lost, there is no option for recovery.

So the impact of bad memory can be more devastating on a system with ZFS than on a system with NTFS, EXT4, XFS, etcetera. ZFS may force you to restore your data from backups sooner.

Wirklich zustimmen kann ich Matthew Ahrens bei diesem Satz:

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

Man beachte die Reihenfolge, erst ECC RAM, dann obendrauf ggf. noch ZFS. ZFS zu empfehlen ohne zu wissen ob ECC RAM und die entsprechende Plattform vorhanden ist, finde ich daher schlicht unseriös.