losgelöst davon, daß ein Raid 1 keine Parität hat, wie ein Raid 5 beispielsweise, trotzdem kann sich ja ein Fehler einschleichen. Gerade beim Software-Raid wesentlich einfacher als beim Hardware-Raid durch einen echten Raid-Controller. Beim Software-Raid kommt noch eine gewisse Verzögerung hinzu, die der Kernel durch Pufferung hier und da hat. Auch kann es sein, daß beide Platten über den selben Controller angesprochen werden, der sich abwechselnd um jeweils eine Platte kümmern muß.
Soll heißen, ich muß ja mein Raid 1 auch irgendwie überprüfen können. Sind denn wirklich alle Informationen von Platte 1 auch auf Platte 2 und umgekehrt natürlich auch. Von da her gibt es in einem Hardware-Raid-1 immer eine "Master"-Platte. Wird also eine Ungereimtheit festgestellt, wird der Datensatz von dieser Master-Platte verwendet.
Ich kann mir schon vorstellen, daß eine Paritätsprüfung bei einem Raid 5 oder Raid 6 wirklich notwendig ist. Denn fällt eine Platte aus, muß man mit der Parity-Information und den restlichen Platten dann die fehlende Platte wieder herstellen. Ist die Parity-Information nicht korrekt, hat man ein Problem. Bei einem Raid 1, kann es sein, daß die zweite Platte z. B. fehlerhafte Datensätze enthält. Fällt die erste Platte aus, wird halt die falsche Information wieder zurück gespiegelt, nachdem die Platte ausgetauscht wurde. Fällt also beim Rebuild nicht ins Gewicht.
Was passiert aber, wenn bei einem Raid 1, beispielsweise wieder die zweite Platte einige defekte Datensätze enthält und es wird gerade eben dieser Datensatz zum Lesen angefordert. Jetzt liest der Raid-Mechanismus die Daten abwechselnd von Platte 1 und Platte 2. Fällt ihm dabei der Fehler nicht auf? Und wenn ja, was macht er dann?
Was ist, wenn bei einem Dateisystemcheck ein solcher Fehler auffällt. Da könnte durchaus das Dateissytem bei einem Reparatur-Versuch zerstört werden. Ziemlich kurios das Ganze..