Matthias Houdek <[EMAIL PROTECTED]> wrote: > Am Samstag, 12. Februar 2005 09:28 schrieb Peter Kuechler: >> Am Freitag, 11. Februar 2005 18:56 schrieb Mario Holbe: >> > Peter Kuechler <[EMAIL PROTECTED]> wrote: >> > > Am Freitag, 11. Februar 2005 13:55 schrieb Matthias Houdek: >> > >> Platten unterschiedliche Ausfälle erzeugen kann (sicher sehr, >> > >> sehr selten, aber nicht auszuschließen). Wenn das System dann >> > >> wieder hochfährt, wird so der bestmögliche Stand >> > >> wirderhergestellt. Es wird wechselseitig abgeglichen. >> > > Klar, macht einen Sinn. >> > Das macht nicht wirklich Sinn, wenn man mal drueber nachdenkt. > Sorry, bin ich vielleicht zu dämlich für. Warum macht das keinen Sinn?
Erstmal sorry fuer das lange quoting, aber irgendwie laesst sich anders der Zusammenhang nicht erhalten. Also... ich versuchs mal geordneterweise auseinanderzuklamuesern. Ein RAID1 heisst erstmal grundsaetzlich: identische Mirrors. Auf jedem Mirror steht genau dasselbe. Steht auf zwei Mirrors nicht dasselbe, ist irgendwas schiefgelaufen, was auch immer. Dann muss man irgendwie die Identitaet wieder herstellen. Soweit sind sich sicher alle hier einig. Wenn ich irgendwie herausfinde, dass auf einem Mirror *nur* neuere Daten stehen und auf dem anderen *nur* aeltere, ist das Herstellen dieser Identitaet offensichtlich unproblematisch. Wenn auf einem Mirror was eines neueres und auf dem anderen was anderes neueres steht, ist irgendwas gar fuerchterlich schiefgelaufen. Versuchen wir mal, eine solche Situation zu konstruieren. Angenommen, wir haben eine Folge von Schreiboperationen auf das RAID: RAID: O1 O2 O3 O4 Konstruieren wir nun eine beliebige Konstellation wie oben beschrieben: Mirror 1: O1 O2 Mirror 2: O1 O4 Da stellt sich natuerlich die gute Frage, wie sowas ueberhaupt entstehen kann. O4 haette auf Mirror 2 garnicht stattfinden duerfen, bevor O2 und O3 nicht abgeschlossen sind. Wenn aber O2 nicht abgeschlossen werden konnte, haette Mirror 2 als defekt markiert werden muessen und O4 haette wiederum garnicht stattfinden duerfen. Well, nehmen wir an, wir haben einen schrecklich fiesen Controller, der Schreiboperationen umgruppiert und entscheidet, O4 vor O2 und O3 auszufuehren - was im uebrigen den zulaessigen Grundannahmen jeder anderen beteiligten Hardware-, Software- und User-Komponente widersprechen wuerde -, dann koennte es zu einer solchen Situation kommen. Gut, ist passiert - wie auch immer... Nach dem Starten des RAID kenne ich die Original-Folge von Schreib- operationen nicht mehr, ich kann nur sehen, dass auf Mirror 2 zwar neuere Daten als auf Mirror 1 gespeichert sind, jedoch einige Daten aelter sind, als auf Mirror 1. Insbesondere bin ich zu diesem Zeitpunkt nicht mehr in der Lage, zu erkennen, ob die Luecke (O3) zwischen den neeueren Daten auf Mirror 1 (O2) und den neueren Daten auf Mirror 2 (O4) existiert oder nicht. Die eigentliche Frage ist nun: Was ist ein bestmoeglicher Zustand? Ein bestmoeglicher Zustand ist - insbesondere in einer solchen Situation - keineswegs der 'neueste', sondern einer, der moeglichst konsistent ist. Man stelle sich ein RAID unter einer Datenbankpartition vor: dort waere es fatal, wenn nach dem Speichern der eigentlichen Daten zwar nicht die Daten selbst, hingegen jedoch die Aenderungen am Transaction-Log, die besagen "Daten wurden gespeichert" sehr wohl geschrieben waeren. Insofern ist also ein moeglichst konsistenter Zustand ein Zustand, der ausschliesslich aus aufeinanderfolgenden Schreiboperationen hervorgegangen sein kann. Wenn ich also nun einen solchen schrecklich fiesen Controller habe, der oben beschriebenes Verhalten aufweist und ich um dieses Verhalten weiss oder aber eine Situation wie beschrieben vorfinde, tue ich genau entgegen der Aussage meiner Vorredner gut daran, mir den *aeltesten* Mirror zu suchen und nach dem zu synchronisieren, weil nur der mir garantiert, dass er aus einer vollstaendigen Folge von Schreib- operationen erzeugt wurde und somit die hoechste Wahrscheinlichkeit fuer eine Konsistenz aufweist. Suchte ich mir den neuesten Mirror oder eine Mischung aus beiden, erhoehte sich die Wahrscheinlichkeit von Luecken in den Schreib- operationen und somit die Wahrscheinlichkeit, in einen inkonsistenten Zustand zu synchronisieren erheblich. Ach ja - nun wird jemand kommen und sagen: "Jaaaa, mein Controller stellt aber sicher, dass die Luecke O3 nie existieren kann". Das ist offensichtlich unmoeglich, da Mirror 1 zu jedem beliebigen Zeitpunkt unwiederbringlich ausfallen kann - ich haette zu diesem Zeitpunkt also lediglich Mirror 2 zur Rekonstruktion zur Verfuegung, auf dem aber offensichtlich O2 und O3 fehlen. Das Problem waere somit dasselbe, wie eben beschrieben. Fazit: *Wenn* ich eine Situation feststelle, in der zwei Mirrors jeweils neuere, aber voneinander verschiedene Daten aufweisen, ist die einzig sinnvolle und zukunftssichere Strategie, den Controller wegzuwerfen. regards, Mario -- User sind wie ideale Gase - sie verteilen sich gleichmaessig ueber alle Platten -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)