Re: RAID consistency check
- From: Lars Dröge <lars-droege@xxxxxxx>
- Date: Thu, 24 Apr 2008 16:10:31 +0200
Am Thu, 24 Apr 2008 13:14:38 +0200 schrieb Georges Heinesch:
[ Fall 1: assume Parity is good.]
Alle Festplatten halten ihre Daten für fehlerfrei, keine erkennt einen
Softerror. Aber die Paritätsprüfung über alle Platten führt zum
Widerspruch.
Ein Softerror wird ja sowieso nicht also Fehlermeldung ausgegeben. Die
Korrektur passiert ja Festplatten-intern und wird vum user bzw. RAID
Controller oder OS gar nicht wahrgenommen.
Korrekt, "Soft" ist hier falsch. So wie ich Punkt #1 jetzt verstehe, muss
die Festplatte nicht einmal angenommen haben, ihre Daten seien fehlerfrei.
Was in den beiden Threads bzgl. RAID (OP: ich) die letzten Tage hier
geschrieben wird, ist ein reiner Lesevorgang, wie er bei einem
consistency check gemacht wird, ja bereits ein "Scrub" (bei dem ein
Softerror entdeckt und korrigiert wird). Wieso ihn alos noch explizit
auswählen?
Der Softerror, den du meinst, ist lokal auf eine Festplatte begrenzt. Das
RAID müsste aber auch einen Bad Block (Harderror) auf einer Festplatte
beheben können. Ich rate mal, dass das hier mit "Scrub" gemeint ist.
_Falls_ eine Festplatte einen Bad Block meldet, so kann das RAID immer noch
die korrekten Daten berechnen und liefern. Unter Punkt #1 kannst du dem
Controller mitteilen, dass der Controller den Bad Block (bzw. einen
Reserveblock der Festplatte) mit den berechneten Daten überschreiben darf.
Die Daten sind natürlich nur dann korrekt, wenn die Daten auf den anderen
Festlatten, korrekt sind. Deshalb wird _deine_ Annahme "Parity Data is
good" vorausgesetzt.
Diese Anweisung, dass Daten überschrieben werden sollen, greift aber nur,
wenn tatsächlich ein Bad Block gefunden wurde. Wenn kein Bad Block gefunden
wird, dann sind alle Festplatten (mit Ausnahme der mit der bereits als
'good' angenommenen Paritätsinformation) gleich (un)vertrauenswürdig. Der
Controller hat dann keine Chance, den logischen Fehler zu beheben.
Das weiß der Controller nicht. Da er es nicht entscheiden kann, fragt er
Dich.
Wie kann ich das entscheiden?
Vermutlich kannst du es nicht. Tröstet es, wenn ich dir sage, dass es auch
sonst niemand kann?
Ich weiss lediglich dass einige Files
korrupt sind (mittels PGP Signature). Da die Nutzdaten dieser Files
natürlich aus den 3 Daten-HDDs kommen, wäre es theoretisch möglich 4
Files auszugeben, eines für jede HDD die ignoriert wird (und
möglicherweise den Fehler enthällt). Technisch ist das von RAID
Controller Hersteller aber nicht implementiert, also kann ich nicht
entscheiden.
Das wäre in deinem Fall tatsächlich wünschenswert, da du anhand der PGP
Signatur die fehlerfreie Datei von den 3 fehlerhaften unterscheiden
könntest.
Aber im allgemeinen ist RAID nur für die Steigerung der Verfügbarkeit
gedacht. Was du jetzt brauchst ist aber ein Backup.
Mit an Sicherheit grenzender Wahrscheinlichkeit habe ich alle daten vor
dem Abspeichervorgang mittels der PGP Signature auf Konsistenz überprüft.
Vielleicht wäre der Fehler eher aufgefallen, wenn du die Konsistenz auch
nach dem Abspeichern auf das RAID durchgeführt hättest, und nicht nur
davor. Auch wenn die Frage jetzt wohl nur noch theoretischer Natur ist,
würde mich interessieren, ob die Daten jemals korrekt auf dem RAID gelegen
haben.
--
MfG
Lars
.
- Follow-Ups:
- Re: RAID consistency check
- From: Georges Heinesch
- Re: RAID consistency check
- References:
- RAID consistency check
- From: Georges Heinesch
- Re: RAID consistency check
- From: Lars Dröge
- Re: RAID consistency check
- From: Georges Heinesch
- RAID consistency check
- Prev by Date: Re: Wie entstehen Festplattenfehler?
- Next by Date: Re: RAID consistency check
- Previous by thread: Re: RAID consistency check
- Next by thread: Re: RAID consistency check
- Index(es):
Relevant Pages
|