Morgen, ich benötige mal fachmännische Hilfe von euch.

 

Ich bin vor kurzen umgezogen und habe ggf. 1-2 den Tower nicht sauber heruntergefahren, weil es schnell gehen musste.

Der letzte monatliche Paritätscheck wurde auch ausgelassen. Daher wollte ich diesen nun nachholen.

 

Dabei ist eine Festplatte disabled wurden, um das Problem zu beheben habe ich eine neue Server-Konfiguration angelegt.

Soweit so gut, damit ist die Parität weg und ich wollte diese wieder herstellen. Eine HDD hat er dann pattu nicht mehr angenommen, wegen kann er nicht mounten. Daher habe ich xfs_repair durchgeführt mit Zero Log und seitdem geht diese auch wieder. Jedoch bekomme ich seitdem weiterhin schlechte Übertragungen und Errors. Ich habe schon ein paar Kabel durchgetauscht, daran scheint es aber nicht unbedingt zu liegen. Ich habe 2x SATA Controller Cards mit je 6 Ports. Vermutung ging auch schon in diese Richtung oder das das Netzteil nicht ausreichend Leistung bringt für alle HDDs.

 

Jedenfalls sind es immer mal wieder andere HDDs die gefühlt Probleme machen. Ich würde bei allen xfs_repair im Wartungsmodus einmal durchführen lassen oder was denkt ihr ist der richtige Weg?

Fehlerlog einer von drei Platten:

 

Feb 13 04:23:26 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED
Feb 13 04:23:26 Tower kernel: ata4.00: cmd 60/18:f0:10:bb:a3/05:00:59:01:00/40 tag 30 ncq dma 667648 in
Feb 13 04:23:26 Tower kernel: ata4.00: status: { DRDY }
Feb 13 04:23:26 Tower kernel: ata4: hard resetting link
Feb 13 04:23:32 Tower kernel: ata4: link is slow to respond, please be patient (ready=0)
Feb 13 04:23:33 Tower kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Feb 13 04:23:33 Tower kernel: ata4.00: configured for UDMA/33
Feb 13 04:23:33 Tower kernel: ata4: EH complete
Feb 13 04:23:34 Tower kernel: ata4.00: exception Emask 0x10 SAct 0x607c00 SErr 0x4090000 action 0xe frozen
Feb 13 04:23:34 Tower kernel: ata4.00: irq_stat 0x00400040, connection status changed
Feb 13 04:23:34 Tower kernel: ata4: SError: { PHYRdyChg 10B8B DevExch }
Feb 13 04:23:34 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED
Feb 13 04:23:34 Tower kernel: ata4.00: cmd 60/40:50:58:c6:a3/05:00:59:01:00/40 tag 10 ncq dma 688128 in
Feb 13 04:23:34 Tower kernel: ata4.00: status: { DRDY }

...........

Feb 13 04:29:30 Tower kernel: ata4.00: exception Emask 0x1 SAct 0x800000 SErr 0x0 action 0x0
Feb 13 04:29:30 Tower kernel: ata4.00: irq_stat 0x40000001
Feb 13 04:29:30 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED
Feb 13 04:29:30 Tower kernel: ata4.00: cmd 60/08:b8:00:00:00/00:00:00:00:00/40 tag 23 ncq dma 4096 in
Feb 13 04:29:30 Tower kernel: ata4.00: status: { DRDY }
Feb 13 04:29:30 Tower kernel: ata4.00: configured for UDMA/133 (device error ignored)
Feb 13 04:29:30 Tower kernel: ata4: EH complete
Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#31 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s
Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#31 Sense Key : 0x2 [current] 
Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#31 ASC=0x4 ASCQ=0x22 
Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#31 CDB: opcode=0x88 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00
Feb 13 04:29:30 Tower kernel: I/O error, dev sdq, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Feb 13 04:29:30 Tower kernel: Buffer I/O error on dev sdq, logical block 0, async page read
Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#13 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s
Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#13 Sense Key : 0x2 [current] 
Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#13 ASC=0x4 ASCQ=0x22 
Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#13 CDB: opcode=0x88 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00
Feb 13 04:29:30 Tower kernel: I/O error, dev sdq, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Feb 13 04:29:30 Tower kernel: Buffer I/O error on dev sdq, logical block 0, async page read
Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#14 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s
Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#14 Sense Key : 0x2 [current] 
Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#14 ASC=0x4 ASCQ=0x22 
Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] tag#14 CDB: opcode=0x88 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00
Feb 13 04:29:30 Tower kernel: I/O error, dev sdq, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Feb 13 04:29:30 Tower kernel: Buffer I/O error on dev sdq, logical block 0, async page read
Feb 13 04:29:30 Tower kernel: sdq: unable to read partition table
Feb 13 04:29:30 Tower kernel: sd 4:0:0:0: [sdq] Attached SCSI disk
Feb 13 04:29:32 Tower kernel: sd 4:0:0:0: [sdq] tag#16 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s
Feb 13 04:29:32 Tower kernel: sd 4:0:0:0: [sdq] tag#16 Sense Key : 0x2 [current] 
Feb 13 04:29:32 Tower kernel: sd 4:0:0:0: [sdq] tag#16 ASC=0x4 ASCQ=0x22 
Feb 13 04:29:32 Tower kernel: sd 4:0:0:0: [sdq] tag#16 CDB: opcode=0x88 88 00 00 00 00 03 a3 81 2a 00 00 00 00 08 00 00
Feb 13 04:29:32 Tower kernel: Buffer I/O error on dev sdq, logical block 1953506624, async page read

Also es war definitiv ein Strom-Problem. 3 HDDs die immer wieder ausstiegen, einzige Gemeinsamkeit: Sie hingen alle an einem Strom-Strang.

Als ich zwei Stränge getauscht hatte, waren es andere HDDs die nicht gingen. HDDs  bzw. die Last umverteilt und siehe da, es geht wieder ohne Ausstieg.

Eventuell liegt es daran, dass ich im BIOS was geändert habe nach dem Umzug, weil Unraid nicht startet, obwohl ich nur den Stick vergaß wieder anzustecken.

Schön Blöd. Auch habe ich den Green-Modus in Unraid mittlerweile aktiviert. Bei allen Platten (ca. 4 weitere) sicherheitshalber anschließend xfs_repair wenn nötig noch durchgeführt. Läuft erstmal wieder. <Bereits 11% der Parität wieder hergestellt>

 

Jedoch beginnt er mit 74 MB/s zu anfang und geht irgendwann nach einigen Stunden runter auf 4 MB/s. Das scheint mir nicht normal zu sein.
Ich kann das zwar beheben, indem ich pausiere und später wieder fortfahre. Aber das ist kein akzeptabler Zustand. Jemand eine Idee?

Was mir noch auffällt ist, dass nach der PAUSE der Mover noch ne Weile läuft. Als ob er Sachen aus dem Cache noch abarbeitet.

Sollte der Cache bzw. die Cache-Platte nicht eigentlich nur für Datentransfer von der Cache-Platte selbst dienen auf HDDs?

Edited February 14, 20251 yr by G0ldenB0Y