Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Hardware>RAID-System, Bit gekippt, wie wird das gehandhabt?

RAID-System, Bit gekippt, wie wird das gehandhabt?

virk
virk06.02.1421:47
Angenommen, es existiere ein RAID1-System mit bspw. zwei Festplatten. Aus welchem Grunde auch immer kippt in einer der beiden Festplatten ein Bit. Was liefert das RAID jetzt aus, wenn auf diesen Bereich zugegriffen wird? Wenn schon die Fragestellung unsinnig ist, dann gehe ich direkt ins Bett

Gute Nacht!

(Der sich aus Studentenzeiten noch erinnert, dass man nach 'nem FestPlatt' war (1st rAID), wenn man, aus welchem Grunde auch immer, mal zu viele Bit kippte, und dann in einigen Bereichen auslief)
„Gaststättenbetrieb sucht für Restaurant und Biergarten Servierer:innen und außen.“
0

Kommentare

SpaceHotte06.02.1421:55

In general, RAID does not provide real-time data integrity checking. What it does provide is fault-tolerance in the face of one (or more, with some RAID levels) drive failures. Those are two very different things.

If you are looking for something to catch file corruption, you need filesystem support. RAID does not do it. At least, not on its own.

To answer your specific questions:

RAID1 is implemented simply as two (or more) identical mirrors. When the mirrors do not agree on the contents of a sector, then corruption has occurred. The thing is, the RAID system is not often in a position to be aware of this, since it does not normally read all the mirrors when it is asked to retrieve a given sector. For efficiency, it will likely just schedule one disk to read it (hopefully the one whose heads are currently nearest to it).

Suppose that, during a "scrubbing" operation, when the RAID system is explicitly asked to verify the consistency of all its data, an inconsistency is discovered. The question of how to resolve this inconsistency has no simple answer. Note that this problem equally affects RAID5 as it does RAID1, and other RAID levels as well.

In a RAID1, an inconsistency appears as two mirror sectors containing different data. How does the RAID system decide which sector represents the correct data? Well, that is an implementation detail, and I honestly don't know how the Linux system is implemented exactly. But the problem is fundamental: the mirrored sectors are different, and there may be no indication as to why they have become that way. So the best the RAID system can do is to flip a coin: choose one at random to be the "correct" data.

In a 3-disk RAID5, an inconsistency appears in the form of a triple of sectors whose parity sector is incorrect. The question is: which of the 3 sectors is wrong? Again, there is no obvious answer. Any of the three could be corrupt, and there's probably no way to know. If you must choose one sector to be recalculated from the other 2, you have 1 in 3 chance of choosing the one that was actually corrupt. This demonstrates that RAID1 is actually "safer" than RAID5, in this sense. The RAID1 has a 50% of choosing the wrong sector, while the RAID5 has a 67% chance of choosing wrongly.

To summarize: RAID is not designed to catch disk errors as they happen. RAID provides fault-tolerance in the face of whole-drive failures. Nothing more.
0
nowMAC06.02.1423:30
Wenn es nur um ein Bit geht wird das (denke ich mal) wie auch ohne raid über die parität-Prüfung. Also das RAID wird das richtige Bit liefern.
„Ne Ne, seit Steve Jobs nicht mehr da ist.... “
0
onicon
onicon07.02.1400:58
So etwas wird schon auf verschiedenen Ebenen (HDD Platter < HDD Controller, Cache < Bus Controller, etc.) via CRC und äquivalenten Mechanismen abgefangen. Für alles Andere gibt es Backups.
0
arekhon
arekhon08.02.1408:14
Also gekippte Bits werden nicht durch ein RAID-1 abgefangen. Dazu reicht auch kein CRC, das schützt nur den Datenpfad bis die Bits gespeichert sind, was danach damit passiert ist nicht mehr abgedeckt. Selbst wenn durchgehend der Datenpfad geschützt ist, dann können nachträglich gekippte Bits nicht wirklich sicher reproduziert werden, dafür müsste man ja wissen welche Version denn nun die korrekte war und das geht nur mit einem Vergleichswert oder über eine eigene Checksumme.
Sichere Mechanismen sind hier z.B. T10-PI (~Diff) oder die Checksummen die ZFS erzeugt. Letztere können aber auch nur dann defekte oder kekippte Bits korrekt rekonstruieren wenn man sie mit RAID-Z oder ähnlicher oder höherer Redundanz ablegt, damit ZFS einen Vergleichswert hat und dann die Variante mit der richtigen Checksumme erkennen und wiederherstellen kann.
RAID1 oder selbst RAID-5 oder -6 allein reichen nicht aus, da ohne Checksumme und Vergleich nicht erkannt werden kann welcher Wert der korrekte ist. Dann kann es im schlimmsten Fall sogar passieren, dass falsche Daten wiederhergestellt werden.
Auch ein Backup schützt nur wenn man feststellen kann wann Daten korrumpiert wurden, wenn das Backup erst angefangen hat die gekippten Bits mit zu sichern, dann ist es schon zu spät.

Also ohne Mechanismen wie T10-PI oder ZFS Checksumming in Verbindung mit RAID-Redundanz seitens ZFS sieht es schlecht aus diese Art Fehler zu korrigieren. Häufig erkennt man sie ohne diese Funktionen nicht einmal.

s.a.
0
arekhon
arekhon08.02.1408:21
Und noch ein Artikel von Seagate

Daraus u.a.:
"But the disparate nature of this approach leads to inconsistent protection,
with solutions such as Error Correcting Code (ECC), Cyclic Redundancy
Check (CRC), checksums, etc. only addressing data corruption at specific,
isolated points in the I/O path. The risk of corrupted data falling through the
inherent cracks in this protection methodology is significant, and the havoc
such undetected, silent data corruption could wreak (lost or inaccurate
data, significant downtime) is substantial."

Raid-1, -5, -6, -10 etc und ECC und CRC reicht eben nicht, weil es nicht über den kompletten Datenpfad und vor Bitrot schützen kann, wie es bisher i.d.R. an den verschiedenen Übergangsstellen implementiert ist.
0
ChrisK
ChrisK08.02.1408:40
Öhm, bei einem RAID-6 sollte es aber möglich sein. Durch die doppelte Parität hat man ja 3 "Meinungen" wie ein Block auszusehen hat und kann dann über Mehrheitsentscheid feststellen welche Platte Murks liefert ... oder?
„Wer anderen eine Bratwurst brät, hat ein Bratwurstbratgerät.“
0
arekhon
arekhon08.02.1408:51
ChrisK
Öhm, bei einem RAID-6 sollte es aber möglich sein. Durch die doppelte Parität hat man ja 3 "Meinungen" wie ein Block auszusehen hat und kann dann über Mehrheitsentscheid feststellen welche Platte Murks liefert ... oder?

In der Theorie, wird aber in der Praxis nicht gemacht und verschwendet mehr Platz als Checksummen + Redundanz. Außerdem ist auch eine 2:1 Mehrheit nicht so sicher wie eine exakte Checksumme mit der man die falsche und richtige Datenvariante eindeutig erkennt.
s.a.:

Edit: Und es kann immer noch passieren das dass Bit woanders im Datenpfad kippt und schon beim Speichern falsch abgelegt wird - doppelt falsch mit RAID gesichert sozusagen. Eine End-to-End Integrität die Schon Server-seitig beginnt und erst mit den bits auf dem Speichermedium endet, ist nicht durch RAID allein ersetzbar.
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.