coltseavers
Goto Top

Buffer I O Error bei SATA Raid1

Hallo zusammen,

ich hab hier nen kleinen Heimserver, bestehend aus einer SSD (Systemplatte) und einem SATA Raid 1 (2x3 TB HDD) an einem Adaptec Raid-Controller ASR-6405E.

Aus einer virtuellen Debian6-Maschine (unter Virtualbox) aus habe ich auf der Platte eine Partition erstellt (ext4) und diese gemountet.
Direkt beim ersten Speicher-Zugriff darauf kommen nun Fehlermeldungen:
Buffer I/O error on device sdb1, logical block 93440
Buffer I/O error on device sdb1, logical block 93441
Buffer I/O error on device sdb1, logical block 93442
...
Buffer I/O error on device sdb1, logical block 93449
blk_update_request: I/O error, dev sdb, sector 751616
blk_update_request: I/O error, dev sdb, sector 753664

Was heisst das denn?

Habe die Suchmaschine gefragt. Die Forenergebnisse meinten, dass "die" Platte defekt wäre. Aber bei nem RAID1 kann das ja kaum sein, oder?
Dann würde ja eigentlich die defekte Platte aus dem Raid fliegen, das System weiterlaufen und der Controller Alarm piepen, korrekt?

Vielen Dank vorab!

Gruß,
Colt

Content-Key: 356768

Url: https://administrator.de/contentid/356768

Ausgedruckt am: 19.03.2024 um 06:03 Uhr

Mitglied: Vision2015
Vision2015 01.12.2017 um 18:10:40 Uhr
Goto Top
moin...
Was heisst das denn?
das eine Platte defekte Sektoren hat!

Habe die Suchmaschine gefragt. Die Forenergebnisse meinten, dass "die" Platte defekt wäre. Aber bei nem RAID1 kann das ja kaum sein, oder?
doch...
Dann würde ja eigentlich die defekte Platte aus dem Raid fliegen, das System weiterlaufen und der Controller Alarm piepen, korrekt?
nö... muss nicht sein...
viele SATA platten bringen die smart fehler nicht an den adaptec... teilweise erst wenn die hdd das zeitliche segnet.
bei einer SAS HDD ist das etwas anderes!
mach mal ein Firmware update... oder hast du den Alarm auf Silent stehen ?

Frank
Mitglied: SamvanRatt
SamvanRatt 02.12.2017 um 00:05:34 Uhr
Goto Top
Hallo Colt
wie Vision2015 schon richtig schrieb werden da "nur" Bad Blocks angemängelt. In wie weit dein ROC Controller zuverlässig mit den Meldungen (der muss als erstes das in sein log schreiben) umgeht kann ich als Adaptec Abstinenz nicht beurteilen; der Preis ist gerade so der Einstieg von Softraid in hardwareRAID Bereich; kann beides sein. Deine VM darf davon aber nichts sehen; wenn sie das sieht greift dein RAID1 nicht.
Solange dein Array genug spare Blocks hat (da gibt es ein Limit ab wann er das nicht mehr verbergen kann) ist für den Controller alles palletti. Sofern du das System offline nehmen kannst nimm eine/beide HDs raus und teste sie extern mittels dd/ddrescue und dumpe sie nach null; geht das ist zumindest lesend alles OK.
Was hast du als hostOS drauf? Der muss weit vor deiner VM Fehler sehen (außer es wird an ihm vorbeigeschummelt, via directpath und Co)

Gruß
Sam
Mitglied: coltseavers
coltseavers 06.12.2017 um 10:35:21 Uhr
Goto Top
Hallo zusammen,

erstmal danke für eure Antworten.
100% verstanden habe ich den Sachverhalt aber noch nicht.

Was ist denn bei meinem o.g. Fehler überhaupt passiert?
Sind da Daten definitiv nicht erfolgreich geschrieben worden? Oder ist das mehr als Hinweis zu verstehen, dass Daten auf einem bestimmten Sektor nicht geschrieben werden konnten, die dann aber auf einen Ersatzsektor geschrieben wurden, sodass der Betrieb ungestört weitergeht?

Zu den angefragten Infos:
Host und Guest sind Debian 9. Alarm steht nicht auf Silent.
Es gibt seit ein paar Monaten ein kleines Firmware-Update, das noch nicht drauf ist (werde ich noch machen) - danke für den Hinweis.

Ich habe beide Platten aus dem Raid1 nun vom Raid-Controller prüfen lassen ("verify disk media", über das config-menü CTRL-A beim Bootvorgang), da hat er dann bei einer Platte Fehler geworfen - die andere war ok.
In der Controller Konfig habe ich nun aktiviert, dass er das Raid automatisch im Hintergrund auf Konsitenz prüfen soll. Ich hoffe er piept dann künftig.

Gruß,
Colt
Mitglied: SamvanRatt
SamvanRatt 06.12.2017 um 11:19:50 Uhr
Goto Top
Hallo Colt
BadBlocks sind (bis zu einer bestimmten HighWaterMark im Controller) kein Piepgrund. Da ich Adaptec und der Firmware seit gut 15 Jahren nicht mehr kenne (ich finde die Firma sehr schlecht; nur ICP war ein guter zugekaufter Zweig) kann ich nicht sagen, ob er da jemals piept.
Gefunden hat er laut Logbuch von dir unlesbare Bereiche (eben BB), das dein OS dies sieht heißt das dein Kontroller seine Arbeit nicht richtig macht, denn dein OS soll bei einem HW RAID Kontroller sowas gar nicht sehen!!! Ein "guter" Kontroller meldet dir dann via SNMP/SMTP das er kleinere Fehler (BB) gefunden hat und gut ist's. Ein "Guter" verschiebt dann die Daten von der guten HD in einen Spare Bereich der schlechten HD und datet seinen (active Adress Block) Table up und ist wieder redundant. Irgendwann gehen dem "Guten" dann die SpareBlocks aus und er muss die HD als Bad piepend rauswerfen. Das machen gute Kontroller (wie Areca, Infortrend, LSI/Broadcom), schlechte (da zählen auch die verkappten ROC Kontroller dazu... nicht halbes nichts ganzes...) haben.
ICH tausche BB HDs immer beim ersten Block aus, nutze privat auch nur "bulletproof Controller" (ich arbeite prof. in der Datenrettung und kann privat einfach keine Probleme daheim brauchen) welche mit Hardwareprobleme abnehmen.
Gruß
Sam