Hi,

ich hatte einen Server-Crash, bei dem sich das Mainboard verabschiedet hat. Daraufhin habe ich das Mainboard durch ein neues getauscht (und dabei gleichzeitig den RAM geupgraded).

Nach dem ersten Startlief das NAS und hat auch einen Partiy-Check im Lesemodus gestartet (hier sichtbar mit den 22 Errors):

Daraufhin hab ich einen Check im Schreibemodus laufen lasen. Der hat dann das 3-Fache gefunden und hoffentlich auch korrigiert.

Nach dem Vorfall wollte ich eine 2. Parity-Platte in das Array einfügen (und das Array davor um eine andere Datenplatte verkleinern). Das würde ich alles aber ungerne machen, wenn ich noch Parity-Errors habe. Deshalb habe ich den 3. Check gestartet, der immer noch etwas gefunden hat. Diesen habe ich dann erstmal abgebrochen.

Ich habe 8 HDDs im Array, 1 davon für Parity. In den SMART-History-Logs meiner Platten gibt es eine einzige mit diesem Eintrag:

ATA Error Count: 1
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 1 occurred at disk power-on lifetime: 192 hours (8 days + 0 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 58 a7 44 df 40  Error: ICRC, ABRT 88 sectors at LBA = 0x00df44a7 = 14632103

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  35 00 38 c8 40 df 40 00      14:53:51.469  WRITE DMA EXT
  25 00 40 00 2a 40 40 00      14:53:51.439  READ DMA EXT
  35 00 28 a0 3c df 40 00      14:53:51.438  WRITE DMA EXT
  25 00 00 e8 57 33 40 00      14:53:51.427  READ DMA EXT
  35 00 00 a0 34 df 40 00      14:53:51.417  WRITE DMA EXT

Smart-Self-Tests lieferten auch keine Ergebnisse.

Meine Fragen:

• Wie finde ich raus, welche Platte ein Problem hat?

• Woran kann es noch liegen, dass die Fehler scheinbar nicht verschwinden oder wieder neue entstehen?

• Sind meine Daten noch sicher?

Edited August 25, 2025Aug 25 by nikeee

6 hours ago, nikeee said:

Daraufhin hab ich einen Check im Schreibemodus laufen lasen. Der hat dann das 3-Fache gefunden und hoffentlich auch korrigiert.

...

6 hours ago, nikeee said:

Smart-Self-Tests lieferten auch keine Ergebnisse.

Meine Fragen:

• Wie finde ich raus, welche Platte ein Problem hat?

• Woran kann es noch liegen, dass die Fehler scheinbar nicht verschwinden oder wieder neue entstehen?

• Sind meine Daten noch sicher?

Parity Error haben weniger mit SMART Error zu tun.

Parity schaut ob die Daten der Festplatten zusammen passen.

SMART sagt etwas zum Zustand der jeweiligen Festplatte aus.

Ob unraid beim Paritycheck schreibt oder nicht, kann man einstellen (im Main Tab ziemlich weit unten ist ein Kreuzchenfeld).

Wenn er zwischen 1.Check Lesend direkt danach gestartetem und 2. Check schreibend mehr Parityfehler findet, deutet das darauf hin, dass sich der Zustand ändert.

Somit ist es auch möglich,d aß der 3. Check wieder andere Fehler zeigt.

Zu den Fragen:

1. Ob es eine einzelne Festplatte ist, weiß man nicht, da der Paritychek immer alle Platten im array prüft.

   Du findest nur heraus, welche Datei(en) betroffen sind (und damit auch auf wlehcer Disk sie liegt/en, wenn Du den Inhalt der Dateoen prüfst.
   Entweder hast Du vorher Checksummen angelegt oder Du hast ein Backup und kannst Das mit Deinen daten vergleichen.

2. Das kann daran liegen, daßß immer wieder neue/andere Fehler gefunden werden.

3. unraid kümmert sich mit der parity um AUsfallsicherheit. Datensicherheit ist eher eine Sache der Backups.

Deine Beschreibung läßt bei mri folgende Frage aufkommen: Du hast Hardware getauscht. hast DU die vor Wirkbetrieb auch mal ausgiebig getestet?
Ein Ramfehler könnte hier eine der möglichen Ursachen sein.

7 hours ago, DataCollector said:

Parity Error haben weniger mit SMART Error zu tun.

Ich hätte hier vermutet, dass eine Platte irgendwelche Probleme hat und deshalb die Parität nicht stimmt. Oder auch ein lockeres SATA-Kabel.

7 hours ago, DataCollector said:

Ob unraid beim Paritycheck schreibt oder nicht, kann man einstellen (im Main Tab ziemlich weit unten ist ein Kreuzchenfeld).

Der erste war nur lesend (weil das ja der default nach einem unexpected shutdown war) und die anderen schreibend. Ich _vermute_ dass er beim 3. Lauf unterschiedliche Fehler geinden hat, aber ich weiß es natürlich nicht.

7 hours ago, DataCollector said:

Du findest nur heraus, welche Datei(en) betroffen sind (und damit auch auf wlehcer Disk sie liegt/en, wenn Du den Inhalt der Dateoen prüfst.

Geht das nicht irgendwie anders? Würde ungern checksummen von 90TB von hand berechnen. Kann man da dem Parity-Check nicht sagen, dass er loggen soll, an welchen Offsets oder inodes die Paritätsprobleme waren? Dann müsste ich nur 8 Dateien anschauen.

7 hours ago, DataCollector said:

Das kann daran liegen, daßß immer wieder neue/andere Fehler gefunden werden.

Wie finde ich raus, warum das scheinbar der Fall ist?

2 hours ago, nikeee said:

Ich _vermute_ dass er beim 3. Lauf unterschiedliche Fehler geinden hat, aber ich weiß es natürlich nicht.

Findest Du im Syslog vielleicht etwas dazu?

Als ich 2022 mal Parity Error suchen wollte hatte ich im Syslog einen Eintrag für jeden Parity Error (Siehe Screenshot unten)

2 hours ago, nikeee said:

Geht das nicht irgendwie anders?

Nicht wirklich, es sei denn Du kennst jede Datei im Kopf und schaust sie Dir an ob die Bits alle richtig sind.

Ich bevorzuge Checksummen (die ich in jedem Verzeichnis für die Dateien darin ablege) und das Ganze dann eben auch noch mit 2 Backups.

Da lase ich sporadisch (wenn Probleme auftauchen oder ich mal an der Harwdare rumgeschraubt habe einen Prüflauf drüber gehen (der bei meiner Datenmenge je nach System zwischen 8 Tagen und einem Monat dauert, aber dann weiß ich genau welche meiner (mir wichtigen) Dateien korrekt sind.

2 hours ago, nikeee said:

Würde ungern checksummen von 90TB von hand berechnen.

Deswegen lasse ich das berechnen, wie auch checken unter Windows mit Batch (und einer exe) Datei machen.

EInmal starten und zurücklehnen.

Nur das Ergebnis der Überprüfung kontrolliere ich noch von Hand (oder besser manuell).

2 hours ago, nikeee said:

Kann man da dem Parity-Check nicht sagen, dass er loggen soll, an welchen Offsets oder inodes die Paritätsprobleme waren?

Siehe Screenshot: er sagt Dir welcher Sektor es ist. aber Du weißt nie auf welcher Platte, weil es immer der selbe Sektor aller Platten ist.

Der Paritycheck interessiert sich nicht für Dateien. Der Paritycheck (und auch die Erzeugung) schaut nur auf die Bits/Sektoren aller Platten und rechnet die zusammen. Ob die ggf. fehlerhafte Stelle nun eine Datei, Metadaten (Datum oder Attribut oder so) oder ein leerer Sektor ist ist dabei vollkommen egal.

2 hours ago, nikeee said:

Dann müsste ich nur 8 Dateien anschauen.

Schau in Dein Syslog. Wenn Du raus bekommst welche Datei auf jeder der Festplatten auf dem betreffenden Sektor liegt kommst Du Deinem Wunsch schon sehr nahe.

Mir fehlen dazu die Linux Kenntnisse.

2 hours ago, nikeee said:

Wie finde ich raus, warum das scheinbar der Fall ist?

Tja, di Fehlersuche ist mehr oder minder ein Austauschen und ausprobieren.

Ich habe auf einem System sporadisch mal auftauchende 5 oder 10 Parityfehler. Aber alle Checksummenprüfungen waren ohne Befund.

Ich kann nur vermuten, das da ein paar relativ unwichtige Metadaten hopps gehen.

3 hours ago, DataCollector said:

aber Du weißt nie auf welcher Platte, weil es immer der selbe Sektor aller Platten ist.

Na das ist doch genau das, was ich gesucht habe. Dann muss ich halt nur 1x auf 8 Platten gucken, was in dem Sektor liegt.

Ich werde das mal probieren.

3 hours ago, nikeee said:

Na das ist doch genau das, was ich gesucht habe. Dann muss ich halt nur 1x auf 8 Platten gucken, was in dem Sektor liegt.

Ich werde das mal probieren.

Wenn Du weist, wie man sieht, welche Datei(Teile) auf dem Sektor liegen, wäre das auch für mich hilfreich. Mein minimales Linuxwissen reicht dabei beiweitem nicht aus

Aktuell lasse ich wieder einen Parity-Check laufen. Dieses mal aber im Maintenance-Mode, bei dem die Dateisysteme nicht gemountet sind.

Ich hab mit dmesg -w mal im Kernel-Log geschaut und sehe auch hier die bereits gefundenen 23 Korrekturen in dieser Form:

[122588.979543] md: recovery thread: P corrected, sector=8358852832

[122588.979552] md: recovery thread: P corrected, sector=8358852840

[122588.979557] md: recovery thread: P corrected, sector=8358852856

Mit dem Sektor und der Blockgröße kann man das Byte-Offset berechnen (Blockgröße ist 512 bei mir):

byte_offset = sektor * block_size

Man bekommt den Block im Dateisystem dann so:
fs_block = byte_offset / <filesystem_blocksize>

Dann kann man mit xfs_db weiter arbieten. Das Problem ist, dass das Dateisystem bei mir mit LUKS verschlüsselt ist. Da die Parität quasi auf Device-Ebene gemanaged ist, komm ich zwar an das kaputte byte, aber weil noch ne Verschlüsselung darüber liegt, nicht direkt an die betroffene Datei. Das würde aber auch dazu führen, dass ein kaputtes byte dann auch direkt den Ganzen Crypto-Block kaputt macht. Je nachdem, was mein XFS da nutzt, sind das dann mindestens 32 byte. Das kann schon ärgerlich werden.

Ich werde das also wohl so akzeptieren müssen.

Weiter habe ich noch ein bisschen analysiert und mit dem Skript einmal die wichtigen SMART-Werte

for disk in /dev/sd?; do

echo "=== $disk ==="

smartctl -a $disk | egrep "Reallocated_Sector_Ct|Reported_Uncorrect|Command_Timeout|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count"

echo

done

Dort habe ich diese Ausgabe bekommen:

/dev/sdh sticht da bei UDMA_CRC_Error_Count heraus, also crc-fehler bei Übertragung. Ich werd das Kabel davon nochmal überprüfen und gucken. Mehr kann ich da glaub ich auch nicht tun.

Ich habe mir die betroffenen Sektoren notiert und werde mal schauen, ob die bei einem erneuten Check deckungsgleich sind.

Danke für deine Hilfe.

Edited August 27, 2025Aug 27 by nikeee