Frage zu Raid-1

    Hi Leute, das hat zwar hier nichts mit dem VDR zu tun, aber ich hoffe trotzdem auf Eure Hilfe:


    Ich habe einen Linux-Server mit ClarkConnect 4.1 Community Edition aufgesetzt( auf einer einzelnen IDE-Platte), Läuft bisher fehlerfrei.
    Jetzt wollte ich einen zusätzliche Datenplatte einbauen, und zwar aus Sicherheitsgrümden im Raid-1
    Dazu habe ich zwei S-ATA HDs eingebaut und angklemmt und folgendes durchfegeführt:
    1. je eine Partition auf /dev/sda und /dev/sdb eingerichtet als primär, volle Größe der HD, Typ fd (Linux raid autodetect) und mit
    2. mdadm -C /dev/md1 -l 1 -n 2 /dev/sda1 /dev/sdb1
    als Raid-1 eingerichtet.
    Wenn ich jetzt mit
    3. mkfs -t ext3 -j /dev/md1 ein Filesystem einrichte, kann ich dieses auch oproblemlos mounten und beschreiben etc.
    /proc/mdstat gibt folgendes aus:
    ---------------------------------------------------------
    Personalities : [raid1]
    md1 : active raid1 sda1[0] sdb1[1]
    39078016 blocks [2/2] [UU]


    unused devices: <none>
    ---------------------------------------------------------
    Allerdings ist die Konfiguration bei jedem Booten weg und es hagelt Fehlermeldungen.
    Das Raid läßt sich händisch problemlos wieder mit
    4. mdadm -A /dev/md1 /dev/sda1 /dev/sdb1 wieder zusammenfügen, ohne das Daten verloren gehen.
    Als "workaround" habe ich (4.) jetzt in /etc/init.d/rc.local eingebaut...
    Das muß aber doch eleganter gehen, oder??
    Ich bin für jeden konstruktiven Vorschlag dankbar!
    Hab ich was wichtiges übersehen und wenn ja, was???

    Registered VDR User #23
    ===========================================
    VDR1: Gen2VDR 3.0beta8
    Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz mit 2GB Ram
    z.Z. mit Intel Onboard Grafik, beim nächsten SW-Update kommt ne nvidia 9300 rein mit VDPAU
    TT2300
    TT3200

    Hallo mad99,


    denke Du hast ein ähnliches Problem wie ich. Die Platten sollten eigentlich vom Kernel erkannt werden und der Raid-Verbund automatisch zusammengefügt werden. Sofern das vom Kernel unterstützt wird (Autodetection) und ein "Persistant Superblock" auf den Platten liegt.


    Was gibt denn ein "mdadm -D /dev/md1" aus?


    Siehe auch mein Post.


    rijo

    DER STILLE:
    Epia ML 6000 EAG; TT-S2300 + TT-S1102 Budget; Transcend 512; 512MB;
    Linvdr 0.7 + Dr. Seltsam Kernel - 2.6.18 + Toxics Patch vdr-1.4.7-ext28-tt-20070523, LinVDR-Updater
    DER SERVER:
    Asus K7V; Athlon 800MHz; 1024MB; FastTrak S150 SX-M 64MB Cache (Raid5); 4xMaxtor 6B200M0;
    SuSE 9.0 (nfs, samba)
    TESTSERVER:
    Asus A8N-SLI Premium; Mahlzeit 4.0beta2

    Habt ihr den Partitionstyp auch auf "raid-autodetect" (Typ fd) umgestellt? Sonst weiss der Kernel nicht, dass die Partitionen zu einem Raidset zusammengestellt werden sollen.


    schick mal ne ausgabe von "fdisk -l /dev/sda"

    VDR: ASUS AT3ION-T, 2GB, Satix S2 Dual, 1TB 2.5", yavdr 0.4
    Server: Intel DH67CF, Pentium G620, 8GB, 2x1000GB 2.5" Raid1, WLAN, Ubuntu 12.04 @22W
    TV: Panasonic P50G30

    Zitat

    Habt ihr den Partitionstyp auch auf "raid-autodetect" (Typ fd) umgestellt?

    Meinerseits ja.


    rijo

    DER STILLE:
    Epia ML 6000 EAG; TT-S2300 + TT-S1102 Budget; Transcend 512; 512MB;
    Linvdr 0.7 + Dr. Seltsam Kernel - 2.6.18 + Toxics Patch vdr-1.4.7-ext28-tt-20070523, LinVDR-Updater
    DER SERVER:
    Asus K7V; Athlon 800MHz; 1024MB; FastTrak S150 SX-M 64MB Cache (Raid5); 4xMaxtor 6B200M0;
    SuSE 9.0 (nfs, samba)
    TESTSERVER:
    Asus A8N-SLI Premium; Mahlzeit 4.0beta2

    ohne dass entsprechende Devices wie z.B. '/dev/mdNN' existieren, kann das Raid nicht gemounted werden. Es ist immer Aufgabe der Hochfahrscripten ein solches Device anzulegen. Wenn dabei nur die Infos von '/proc/mdstat' ausgewertet werden sollen, sollte ein 'mdadm --assemble --scan --auto=yes --symlink=no' hierzu ausreichen.

    Zitat

    ohne dass entsprechende Devices wie z.B. '/dev/mdNN' existieren, kann das Raid nicht gemounted werden.


    Soweit klar.



    Zitat

    Es ist immer Aufgabe der Hochfahrscripten ein solches Device anzulegen.


    Wenn ich das richtig gelesen habe, kann das auch vom Kernel erledigt werden. Das erkennt die ID der Partition (Linux Raid Autodetect), holt sich die Informationen aus dem "Persistent Superblock" und startet dann das Raid auf dem entsprechenden Knoten /dev/mdx. Dies sollte eigentlich ohne Script und Konfigurationsdatei funktionieren, vorrausgesetzt das Kernel unterstützt die "Autodetection" der Softwareraidplatten (was ich beim Dr. Seltsam Kernel nicht weiß).


    Sollte ich falsch liegen oder meine Erklärung nicht korrekt/vollständig sein bitte ich um Nachsicht und Korrektur. Bin noch nicht wirklich hinter die Geschichte gekommen. :schiel


    rijo

    DER STILLE:
    Epia ML 6000 EAG; TT-S2300 + TT-S1102 Budget; Transcend 512; 512MB;
    Linvdr 0.7 + Dr. Seltsam Kernel - 2.6.18 + Toxics Patch vdr-1.4.7-ext28-tt-20070523, LinVDR-Updater
    DER SERVER:
    Asus K7V; Athlon 800MHz; 1024MB; FastTrak S150 SX-M 64MB Cache (Raid5); 4xMaxtor 6B200M0;
    SuSE 9.0 (nfs, samba)
    TESTSERVER:
    Asus A8N-SLI Premium; Mahlzeit 4.0beta2

    dass der Kernel das Raid wie gewuenscht erkennt, zeigt ja bereits die korrekte Ausgabe der Daten mit 'cat /proc/mdstat'. Das Mounten der Raid-Partitionen muss aber immer explizit (z.B. mit Scripten) gemacht werden.


    Ist das Root-FS selbst schon auf einem Raid, gibt man das in den Kernel Args mit z.B. '... root=/dev/md0 ...' an. Dann wird das Root-FS z.B. von der 'initrd' unter Zuhilfenahme von 'mdadm' und 'mount' gemountet. Es muss ja auch hier das '/dev/md0' erst mal angelegt werden.


    Die Devicenamen anderer Raid-Partitionen werden im Laufe des Hochfahrprozesses von Scripten wie '/etc/rcS.d/S25mdadm-raid' (Debian) erzeugt. Und wie gewoehnlich ueber '/etc/fstab' dazugemounted.

    Zitat

    dass der Kernel das Raid wie gewuenscht erkennt, zeigt ja bereits die korrekte Ausgabe der Daten mit 'cat /proc/mdstat'. Das Mounten der Raid-Partitionen muss aber immer explizit (z.B. mit Scripten) gemacht werden.


    Bei meiner Istallation habe ich am Anfang der rcStart ein "mdadm -As /dev/md0" eingefügt. Das ist notwendig weil der Kernel das Raid sonst nicht automatisch auf /dev/md0 anlegt. Kommentiere ich diese Zeile aus ergibt "cat /proc/mdstat" nach einem Neustart ein "unused devices: <none>" also kein Raid. Mit der Zeile "mdadm -As /dev/md0" in der rcStart wird das Raid korrekt in der mdstat aufgelistet. Das anschließende mounten über die fstab oder von Hand ist dann kein Problem mehr. Übrigens ist es für dieses Verhalten unerheblich ob die Platten eine "fd"-ID haben oder nicht.


    Dachte ursprünglich dass das Anlegen des Raids (wie es unter "mdadm -As /dev/md0" geschieht) auch vom Kernel übernommen werden kann. Siehe letzte Antwort.


    rijo

    DER STILLE:
    Epia ML 6000 EAG; TT-S2300 + TT-S1102 Budget; Transcend 512; 512MB;
    Linvdr 0.7 + Dr. Seltsam Kernel - 2.6.18 + Toxics Patch vdr-1.4.7-ext28-tt-20070523, LinVDR-Updater
    DER SERVER:
    Asus K7V; Athlon 800MHz; 1024MB; FastTrak S150 SX-M 64MB Cache (Raid5); 4xMaxtor 6B200M0;
    SuSE 9.0 (nfs, samba)
    TESTSERVER:
    Asus A8N-SLI Premium; Mahlzeit 4.0beta2

    ein mdadm ist nicht manuell notwendig, das kann der kernel an sich ganz gut alleine. Hier mal das beispiel von Fedora:



    Kanns sein, dass du den Multi-device support nicht im kernel hast? Sieht bei mir so aus:


    #
    # Multi-device support (RAID and LVM)
    #
    CONFIG_MD=y
    CONFIG_BLK_DEV_MD=y
    CONFIG_MD_LINEAR=m
    CONFIG_MD_RAID0=m
    CONFIG_MD_RAID1=m
    CONFIG_MD_RAID10=m
    CONFIG_MD_RAID456=m
    CONFIG_MD_RAID5_RESHAPE=y
    CONFIG_MD_MULTIPATH=m
    CONFIG_MD_FAULTY=m
    CONFIG_BLK_DEV_DM=m
    CONFIG_DM_DEBUG=y
    CONFIG_DM_CRYPT=m
    CONFIG_DM_SNAPSHOT=m
    CONFIG_DM_MIRROR=m
    CONFIG_DM_ZERO=m
    CONFIG_DM_MULTIPATH=m
    CONFIG_DM_MULTIPATH_EMC=m


    Ausserdem habe ich das sata-modul in der initrd, weil er sonst beim autodetect die sata-platten noch nicht hat.

    VDR: ASUS AT3ION-T, 2GB, Satix S2 Dual, 1TB 2.5", yavdr 0.4
    Server: Intel DH67CF, Pentium G620, 8GB, 2x1000GB 2.5" Raid1, WLAN, Ubuntu 12.04 @22W
    TV: Panasonic P50G30

    Ich zitiere mich ungern selbst, aber
    1. je eine Partition auf /dev/sda und /dev/sdb eingerichtet als primär, volle Größe der HD, Typ fd (Linux raid autodetect)



    Da ich beim ClarkConnect keine Kernelsourcen gefunden habe, kann ich auch den Kernel nicht neu kompilieren.
    Da ich aber mit einem einfachen mdadm -A /dev/md1 /dev/sda1 /dev/sdb1
    das Raid wieder in Betrieb nehmen kann, vermute ih diooch, das die Raisfunktionalität vorhanden ist, oder?


    Aber die MD-Ausgaben beim hochfahren bekomme ich nicht. Zur Zeit kann ich an den Rechner leider nicht dran.Muß ich mir heute Nacht nach Feierabend anschauen.


    Aber im Prinzip ist das verhalten unkritisch, wenn auch unschön??
    Kein größeres Risiko für meine Daten?

    Registered VDR User #23
    ===========================================
    VDR1: Gen2VDR 3.0beta8
    Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz mit 2GB Ram
    z.Z. mit Intel Onboard Grafik, beim nächsten SW-Update kommt ne nvidia 9300 rein mit VDPAU
    TT2300
    TT3200

    unkritisch aber laestig, wuerd ich sagen.


    ich koennte mir vorstellen, dass der "mdadm" die notwendigen md-module nachlaedt, und damit die /dev/md? Devices erzeugt.


    schick mal ein "lsmod | grep md" und "lsmod | grep raid"


    Eventuell reicht dir, eine neue initrd mit den notwendigen modulen zu basteln. Wenn du aber mit dem jetzigen Verhalten leben kannst, wuerd ich es lassen. ohne richtig initrd bootet das ding halt ueberhaupt nicht mehr...

    VDR: ASUS AT3ION-T, 2GB, Satix S2 Dual, 1TB 2.5", yavdr 0.4
    Server: Intel DH67CF, Pentium G620, 8GB, 2x1000GB 2.5" Raid1, WLAN, Ubuntu 12.04 @22W
    TV: Panasonic P50G30

    Zitat

    Originally posted by andreash
    ein mdadm ist nicht manuell notwendig, das kann der kernel an sich ganz gut alleine.


    aber nur wenn die erforderlichen Module nicht erst zur Laufzeit nachgeladen werden.


    So eine Konstruktion ist aber normalerweise nur fuer ein System ohne initrd mit Root-FS auf Raid erforderlich.

    Ich hab jetzt in /etc/rc.d/rc.sysinit
    den Eintrag der m.E. fürs korrekte Einbinden zustaändig ist, durch mein Kommanda ersetzt ergänzt und jetzt gehts einwandfrei ;)
    Wenn ich das Script richtig gelesen habe, freift es auf /etc/mdadm.conf zu und das File scheint nicht korrekt zu sein, obwohl es von mdadm selbst erzeugt wurde.
    Ist mir jetzt aber auch egal, da ich einen (für mich) akzeptablen workaround gefunden habe!
    Beim nächsten Mal werde ich das dann korrekt lösen.



    Auf jeden Fall vielen Dank für Eure rege Mithilfe!

    Registered VDR User #23
    ===========================================
    VDR1: Gen2VDR 3.0beta8
    Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz mit 2GB Ram
    z.Z. mit Intel Onboard Grafik, beim nächsten SW-Update kommt ne nvidia 9300 rein mit VDPAU
    TT2300
    TT3200

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden