Hallo Manfred Am Monday 01 June 2009 18:45:36 schrieb Manfred Kreisl:
Emil Stephan schrieb:
Am Sunday 31 May 2009 12:45:32 schrieb Manfred Kreisl:
1464613920
Hallo Manfred,
Ad1: KMail hat Deinen Text verschluckt, ich wollte aber eh nicht Alles hier
Macht nix, kann sie dir ja per PM nochmal schicken ;-) brauchst Du nicht, habe ich noch hier.
drin haben. Jetzt zum eigentlichen Thema:
Das ist eine haarige Situation, mit der ich auch keine Erfahrung habe; also vorsichtig sein und weitere Meinungen abwarten.
ACK
Was mir auffällt, ist, dass Du einen RAID-Superblock in der Version 1.00 hast; bei der OpenSuse 11.0 (kurz OS genannt) ist 00.90 aber der Default. Beide
Bist du dir da sicher? Ich hab die Raids mit Yast eingerichtet, sowohl das RAID1 (welches ja ok ist) als auch das RAID5 hat Metadata 1.0 Hat mich zugegebenermaßen auch etwas irritiert. Also meine RAID-Superblocks sind von der Version 00.90. Diese habe ich allerdings nicht mit yast, sondern mit mdadm eingerichtet.
RAID-Superblock-Varianten befinden sich persistent am Ende der Komponenten-Geräte (also der /dev/sd*). Normalerweise werden RAID-Arrays mit persistentem RAID-Superblock mit dem Kommando: mdadm --assemble --scan oder kurz mdadm -A -s zusammengefügt. Hattest Du das vorher im Rettungssystem ausprobiert?
Nein, wie geschrieben KNOPPIX 5.3, erst nachdem es passiert ist hab ich das Rettungssystem der 11.1 konsultiert
Den Parameter --force würde ich erst mal weglassen, um bei der Analyse keine gefährlichen Operationen zu veranlassen.
Ich hatte es zuerst ohne und dann mit --force probiert, verändert hat das allerdings nichts
Nach meiner Meinung sind MD-RAID-Arrays zur Zeit noch sehr empfindlich in Bezug auf die Version des Kernel-Treibers (*1), also bitte auch auf die Kernel-Versionen achten.
Na toll, ich hab hier den 2.6.28.7 und KNOPPIX hat den 2.6.24 Mit der 2.6.24 habe ich leider keine Erfahrung mit RAID. Die 2,6,28,7 hat in der von mir erwarteten Weise funktioniert, Sprich, der Kernel hat die Arrays automatisch zusammengefügt. Aber das Problem mit /dev/md2p1 sollte nach meinem Verständnis für Dich keine Rolle spielen, weil Du ein LVM darüber gelegt hast. Die Partitionierung wird dann vermutlich mit LVM abgewickelt. Das will und werde ich auch nicht testen, weil ich diese Vermischung von RAID und LVM, gelinde gesagt, nicht gut finde,
Wenn da verschiedene Treiber-Versionen im Spiel sind, könnte ich mir vorstellen, dass ein 'mdadm --grow --size=max', ausgeführt im Rettungssystem, helfen könnte, wenn der RAID-Superblock erkannt worden ist. Durch die Angaben
Das Problem ist dass der grow nur für aktive Raids anwendbar ist, und gerade aktivieren kann ich es ja nicht.+ Nach Deinem 'mdadm --detail ...' wird es aber als active ausgewiesen, aber nicht als Started. Hast Du mal /proc/mdstat per cat bemüht?
in der Kommandozeile kann das aber verhindert worden sein. Alternativ kannst Du Deinen Taschenrechner bemühen und die Array-Größe selbst berechnen. Frag mich aber nicht nach einer Formel, die würde ich vor der Überprüfung an einem Test-Array nicht formulieren. Es ist Dein Risiko, siehe oben.
Ja, das ist mir klar. Ich hab übrigens zwei Raid Tools gefunden die aber unter Windows laufen und nicht (lt. Beschreibung zumindest) LVM's unterstützen. Also nützen mir die nix. Genau, die werden mit ganz anderen Verwaltungstrukturen arbeiten und somit sogar höchst gefährlich sein können.
Mittlerweile habe ich übrigens vom Tape mein System wieder in einen unbenutzten Teil einer 1TB Platte restauriert und es läuft wieder eine Art "Notbetrieb", allerdings ohne die Raids. Ich geb da dir Hoffnung noch nicht auf.
1:) Treiber aus den OS-Kernel (2.6.25.x in OS11.0 bzw. 1.6.27.x in OS 11.1) können keine Partitionen auf RAID-Arrays verarbeiten (udev-Events
Dann verstehe ich nicht dass meine Tests in einer VM sowohl mit 11.0 als auch mit 11.1 problemlos geklappt hatten. Allerdings immer ohne den vermaledeiten grow Befehl, der mich ja offensichtlich erst in den Schlamassel gebracht hat Ich habe das bewusst als Randnotiz an das Ende gestellt, weil es bei Dir im Zusammenhang mit LVM nicht relevant sein dürfte.
für /dev/md2p1 scheinen zu fehlen) , wohingegen bei 2.6.28 und 2.6.29 diese Geräteknoten erzeugt werden
Gruß Manfred
Wenn --grow nicht mehr geht, weil nicht aktiv( oder nicht gestartet, was auch immer), und ein Notsystem aktiv ist, würde ich es riskieren, das Array mit mdadm neu anzulegen, nicht mit yast, und neu zu befüllen. Und nicht vergessen /etc/mdadm.conf zu editieren, denn da sollte die UUID drinstehen. Tschö, Emil -- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org