[Eisfair] Problem mit Softraid oder ist es ein HW Problem?

[Kay Martinen]

Hallo All

ich hätte da ein paar; eventuell Hilfreiche; Kommentare, obwohl ich auch 
kein Experte bin mit so etwas und nicht behaupten will das meine 
Vermutungen zu träfen. Just FYI

Am 21.11.2017 um 17:42 schrieb Marcus Roeckrath:
> 
> ata4.00: FLUSH failed Emask 0x4
> ata4.00: disabled
> ata4.00: device reported invalid CHS sector 0
> ata4: hard resetting link
> ata3.00: FLUSH failed Emask 0x4
> ata3.00: disabled
> ata3.00: device reported invalid CHS sector 0

An das invalid Sector erinnere ich nicht, aber der Rest kommt mir 
Bekannt vor von meinem neulich erst geschildertem Problem mit den beiden 
P-ATA Desktop-Platten im Raid 1. Da fiel auch nach beliebig langer zeit 
immer wieder mal eine aus dem Raid. Mal war es ein halbes Jahr, mal ein 
Monat oder 2 Wochen.


> Komisch ist, dass zwei Platten zum gleichen Zeitpunkt aussteigen.
> Warum sollten zwei Platten exakt zum gleichen Zeitpunkt ein Problem haben.

Mögliche Erkläre s.u.
> 
> Hat das Board eventuell mehrere SATA-Controller und hängen sdd und sde an
> einem anderen als sdb und sdc?
> 
> Da ist der erste Controller (ata1/2):
> 
> ata_piix 0000:00:1f.2: version 2.13
> ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
> ata1: SATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0x1c10 irq 14
> ata2: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1c18 irq 15
> 
> Hier der zweite (ata3/4), welches genau sdd und sde sind, die aussteigen:
> 
> ata_piix 0000:00:1f.5: MAP [ P0 -- P1 -- ]
> ata3: SATA max UDMA/133 cmd 0x1c68 ctl 0x1c5c bmdma 0x1c30 irq 17
> ata4: SATA max UDMA/133 cmd 0x1c60 ctl 0x1c58 bmdma 0x1c38 irq 17

Hier fällt mir auf das es doch eigentlich 4 Controller sein dürften von 
denen vermutlich jeder zwei Ports bedient. Die letzten Beiden teilen 
sich aber einen IRQ. Die anderen beiden haben jeweils eigene. Da ich 
vorher was von lost interrupt las könnte das eine Spur sein.

Denn offenbar sind Bootplatte und CD mit 2 Platten an den ersten beiden 
Controllern. Wobei man annehmen kann das von CD und Bootplatte nur wenig 
Transfers und damit interrupts generiert werden. Bleibt evtl. immer noch 
luft für die beiden Platten des Raid. Aber auf den anderen Controllern 
müssen sich beide Raid-platten einen IRQ teilen.

Nun sind da mehrere RAID 5 als SoftRaid drauf. D.h. es wird Parity 
berechnet und abwechselnd über jede platte geschrieben und generell sind 
alle 4 platten eher gleich stark im Zugriff (wenn ich die Systematik 
richtig erinnere). Die Berechnungen erledigt die CPU, aber das Ergebnis 
muss ja auf 4 Platten und über drei IRQ verteilt werden. Logischerweise 
werden die letzteren da wohl stärker belastet. Die die ausfallen.


> 
> Das hängt jeweils dran:
> 
> ata4.00: ATA-9: WDC WD20EFRX-68EUZN0, 82.00A82, max UDMA/133
> ata3.00: ATA-8: ST2000DM001-9YN164, CC4B, max UDMA/133

Was heißt hier eigentlich CC4B und warum steht es überall nur nicht bei 
der WD?

> 
> Also: Wieso steigen genau die Platten an dem einen Controller zeitgleich
> aus?

Kurze suche ergibt das die Seagate zwar eine Barracuda ist, aber ein 
Desktop-Modell. Die WD dagegen sehe ich als WD RED und die ist für 
Dauerbetrieb gedacht.

Witzig daran auch: In einem Datenblatt finde ich zu der Seagate die Angabe

Power On Hours: 2400

Was 100 Tagen entspräche. Ich interpretiere das so das diese Platte 
maximal 100 Tage eingeschaltet sein darf und dann keine Gewähr für ihre 
Funktion mehr besteht. Sprich: erhöhte Fehlerquote. Welcher Desktop 
läuft schon so lange...

Da die WD RED vermutlich TLER kennt, die Seagate als Desktop-Platte wohl 
eher nicht könnte dies ein Weitere Grund sein. Vielleicht sogar die 
eigentliche Initialzündung für einen Ausfall. Wenn ein Sektor nicht 
sofort geliefert werden kann gibt die WD früher auf, die Seagate spät.

Keine Ahnung was der Raid-Support im Kernel dann daraus macht, ein 
Ergebnis wie oben scheint mir aber denkbar.

Das es offenbar bei den Anderen Seagate nicht auftritt könnte daran 
liegen das sie an Controllern mit unterschiedlichen Interrupts hängen 
und zusammen mit weniger ausgelasteten Laufwerken (Boot und CD). Ich 
nehme jedenfalls an das die Timeouts für das Warten auf einen 
Plattenzyklus zumindest pro Controller getrennt laufen.

Zuletzt: Mir fiel ein das vor einigen Jahren eine Bestimmte 
Mainboard-Serie ein Datenproblem mit einem S-ATA Controller hatte der 
NICHT der erste war (2. oder 3.). Dort soll es zu korrupten Daten 
gekommen sein. Details erinnere ich nicht. Aber evtl. hilfreich mal die 
Errata für das Mainboard zu Checken.

Das wars. Vielleicht was Hilfreiches dabei...

  Kay