Am Dienstag, 15. Februar 2005 13:37 schrieb Mario Holbe:
> Matthias Houdek <[EMAIL PROTECTED]> wrote:
> > Am Dienstag, 15. Februar 2005 09:25 schrieb Mario Holbe:
> >> RAID: O1 O2 O3 O4
> >> Mirror 1: O1 O2
> >> Mirror 2: O1 O4
> >
> > Warum so kompliziert? Das ist nun wirklich ein Fall, der nicht
> > auftreten
>
> Weil das der Fall ist, den mein Vorredner (weiss nicht, ob Du das
> warst) beschrieben hat: Ein Mirror hat an einer Stelle neuere Daten,
> ein anderer Mirror hat an einer anderen Stelle neuere Daten.
>
> > d�rfte und der leider auch durch ein RAID nicht gefixed werden
> > kann.
>
> Genau.
>
> > Warum nicht was einfacheres?
> > Mirror 1: 01 02 -Fehler- Ersatzsektor noch nicht lokalisiert \
> > Mirror 2: 01 02 03 /
> > crash
>
> Weil das nicht der Fall ist, wie ihn besagter Vorredner urspruenglich
> beschrieben hat. Der Fall den Du hier hast, ist der Trivialfall.
Jepp.
Aber auch der andere Fall ist IMHO konstruierbar, wenn die Platte einen
Schreib-Cache hat (und ich bin mir nicht sicher, ob das nur eine reiner
FIFO ist - ich bin zu wenig Hardware-Schmied ;-):
Mirror 1 (cache): (01) (02) (03) (04) |
Mirror 1 (disk): ->(01) ->Err ->Err ->(04) |
'--------'------------->|crash
Mirror 2 (cache): (01) (02) (03) (04) |
Mirror 2 (disk): ->(01) ->(02) ->Err ->Err |
'--------'---->|crash
Durch den Systemcrash wurden die f�r den Controller geschriebenen, aber
von der Platte noch im Schreibcache gehaltenen Daten vernichtet.
�brig bleibt:
Mirror 1 (disk): (01) (04)
Mirror 2 (disk): (01) (02)
Wobei die L�cke dazwischen noch unwahrscheinlicher ist als der Fall
unterschiedlicher neuer Daten an sich.
> > Nach dem Crash wird das System wieder hochgefahren und das RAID
> > erkennt die Differenz. UNd nun?
>
> Nun ist ganz offensichtlich, dass Mirror 2 als Quelle fuer die
> Synchronisation von Mirror 1 herhalten muss, weil Mirror 2 neuer
> ist.
Genau das war der "casus knackus". Die Grundaussage, der ich stets
widersprochen habe, war: Ein RAID-1 kann man als (sicheres) Backup
verwenden, indem man die eine Platte im Rotationsverfahren wechselt.
Mein Gegenargument: Dann kann ich mir ein inkonsistentes System
einfangen - sicherlich selten, aber es ist m�glich (weil eben gerade
solche F�lle auftreten k�nnen, dass von der neu eingesetzten Platte aus
synchronisiert wird).
Einziger Ausweg: Man l�st das RAID vollst�ndig auf, tauscht die Platte
und setzt das RAID neu auf, und zwar mit der im System verbleibenen
Platte als Master f�r die Erstsynchronisation. Und das ist ja nun alles
andere als leicht und unkompliziert zu handhaben.
> Es sei denn, ich habe einen dieser von mir beschriebenen kranken
> Controller, wo ich micht nicht drauf verlassen kann, dass zwischen
> 02 und 03 nichts anderes mehr war. *Dann* taete ich, wie und warum
> beschrieben, gut daran, aus Konsistenzgruenden den aelteren Mirror
> zu nehmen.
>
> > So, wie ich dich und verstanden habe, wird der Zustand von Mirror 1
> > auf Mirror 2 synchronisiert und nie anders herum. Warum nicht?
> > Warum macht das keinen Sinn?
>
> Wer sagt das?
Das war die Kernaussage, warum man Platte 2 stetig und gefahrlos im RAID
im Rotationsprinzip als "Backup-Platte" wechseln kann.
> >> Wenn ich also nun einen solchen schrecklich fiesen Controller
> >> habe,
>
> ...
>
> > Ah, ja. Und der �lteste Mirror ist unbestritten der, der
> > zwischenzeitlich als Backup im Schrank lag. Uff ...
>
> Welchen Teil von "Wenn ich also nun einen solchen schrecklich fiesen
> Controller habe" hast Du nicht verstanden?
"nun" ;-)
> >> Fazit: *Wenn* ich eine Situation feststelle, in der zwei Mirrors
> >> jeweils neuere, aber voneinander verschiedene Daten aufweisen, ist
> >
> > Aber genau diese Situation kann man gerade beim st�ndigen Aufl�sen
> > und Wiederherstellen der RAIDs zum Wechseln der Platten erzeugen.
> > Wie du
>
> Nein, eine solche Situation kann man genau *nie* erzeugen, sofern
> man einen vernuenftigen Controller und ein vernuenftiges RAID-System
> hat.
>
> > Wird aber eine Platte aus dem RAID gerissen, so sollte man sie
> > danach nicht wieder in das selbe RAID hinzuf�gen (au�er als
> > "saubere, neue" Platte). Das Ergebnis der Synchronisation kann
> > sonst im Einzelfall sehr b�se aussehen, wie du eindrucksvoll oben
> > geschildert hat (und was ich die ganze Zeit auch deutlich zu machen
> > versuchte).
>
> Nein, da man eine solche von mir geschilderte Situation mit einem
> vernuenftigen System nie erhalten wird.
Wenn sich Systeme immer vern�nftig und der Logik folgend verhalten
w�rden, br�uchte man viel seltener ein Backup.
> Nochmal zum Verstaendnis: Die von mir geschilderte Situation ist die
> einzige, in der es zu einer wechselseitigen Synchronisation, wie von
> einem meiner Vorredner (weiss nicht, ob von Dir) geschildert, kommen
> koennte.
Schon mal bedacht, dass auch Daten eventuell problemlos schreibbar, aber
sp�ter nicht mehr lesbar sein k�nnen? So, als w�ren sie nie
geschrieben?
> Eine solche Situation ist mit vernuenftigen Komponenten
> schlicht undenkbar und praktisch nicht herstellbar, es sei denn, es
> existiere und man verwende die von mir konstruierte kranke Hard-/
> Software. Entsprechend ist auch die von besagtem Vorredner
> beschriebene wechselseitige Synchronisation Unsinn. Einzig und allein
> der Darlegung ebenjenen Umstandes diente diese meine Konstruktion.
Schade, dass ich die Unterlagen nicht mehr hab. Ich w�rde die Passage
bestimmt wieder finden (vielleicht hab ich sie auch flasch
interpretiert - aber zumindest macht es in bestimmten F�llen IMHO Sinn,
das zu k�nnen).
--
Gru�
����������������MaxX
Hinweis: PMs an diese Adresse werden automatisch vernichtet.
