Request for contribution: SW-RAID
Hoi!
We are working on improving software (SW) RAID support within grml and would appreciate your help and opion about it. Please contribute!
As you maybe know, partitions of type 0xfd (Linux raid autodetect) are scanned and automatically assembled into RAID arrays by the kernel. We noticed a strange behaviour on automatic assembling (nothing serious but a little bit confusing) and try to figure out what's the reason for it.
First of all some questions to the ones of you using SW-RAID:
* If you boot grml on a box using SW-RAID: do you expect to get a running SW-RAID setup (using the /dev/md? devices) or do you prefer to set it up and start on your own (so neither grml nor kernel touches it)?
* Say you have /dev/hda1 and /dev/hdb1 as part of SW-RAID /dev/md0. Do you expect to get entries for /dev/hda1, /dev/hdb1 and /dev/md0 in your /etc/fstab? Which entries do you expect to get?
Next step: If you have a SW-RAID setup and can boot grml on the box please try to contribute via running the following steps and save output of all commands in a file. Send the file via mail to me. This would help us in debugging a lot!
############################################################################# Boot grml and check, whether the SW-RAID is running [via 'cat /proc/mdstat'].
If yes (SW-RAID is running automatically after booting grml):
# cat /proc/mdstat # mdadm --detail /dev/md? # fdisk -l /dev/md? /dev/hd? /dev/sd? # run this for all your raid-devices and harddisk partitions # cat /etc/fstab
If no (SW-RAID is not running automatically after booting grml):
# cat /etc/fstab # mdrun # rebuildfstab -r -u grml -g grml # cat /etc/fstab
Is the SW-RAID running now? If yes please start again at the beginning. #############################################################################
And finally: please join the #grml channel on irc.freenode.org if you have any feedback regarding SW-RAID so we can talk to you. If you want to reply via mail please send it either to me or to grml@mur.at (as suggested via Reply-To:).
thx && regards, -mika-
Hoi!
Thanks to the ones who contributed. Finally we have a solution which should be acceptable.
* Michael Prokop mika@grml.org [20060217 14:45]:
We are working on improving software (SW) RAID support within grml and would appreciate your help and opion about it. Please contribute!
As you maybe know, partitions of type 0xfd (Linux raid autodetect) are scanned and automatically assembled into RAID arrays by the kernel. We noticed a strange behaviour on automatic assembling (nothing serious but a little bit confusing) and try to figure out what's the reason for it.
Linux raid autodetect devices (0xfd) are assembled by default on grml. That's working currently and as long as upstream does not remove this features (see linux.raid mailinglist for details) we will support it as well.
- If you boot grml on a box using SW-RAID: do you expect to get a running SW-RAID setup (using the /dev/md? devices) or do you prefer to set it up and start on your own (so neither grml nor kernel touches it)?
Automatic assembling of md works if kernel supports the device(s) and because md is compiled statically into our kernel.
Accesssing devices works on P-ATA devices, but not on (all) S-ATA and SCSI devices as all the S-ATA/SCSI modules would have to be part of the kernel (statically compiled).
So if you have a md running on S-ATA/SCSI which is not started by default just run 'mdrun' after booting grml. Take a look at 'cat /proc/mdstat' to check which and whether devices are up and running.
If you absolutely do not want to use the automatic assembling of SW-RAID use the kernel commandline 'raid=noautodetect'. So boot your grml system via 'grml raid=noautodetect'. This has been added to the forensic cheatcode as well (for next versions of grml).
- Say you have /dev/hda1 and /dev/hdb1 as part of SW-RAID /dev/md0. Do you expect to get entries for /dev/hda1, /dev/hdb1 and /dev/md0 in your /etc/fstab? Which entries do you expect to get?
You will get entries for "/dev/md?" coresponding to the filesystem type on the device. It is not mounted by default and mounting is restricted to user root.
You will also get entries named "/dev/hd?" with filesystem type linux_raid_member if the device is part of a linux raid. As for "/dev/md?" they are not mounted by default, mounting is restricted to user root and mounting won't work for security reasons due to filesystem linux_raid_member.
[...]
The above information will apply for grml releases starting with the upcoming development release grml 0.6-2. If you notice anything which does not behave as documented feel free to submit a bug report to me. Thank you.
HTH, JFYI && regards, -mika-
High, high ... * Michael Prokop mika@grml.org schrieb am [17.02.06 14:31]:
Hoi!
We are working on improving software (SW) RAID support within grml and would appreciate your help and opion about it. Please contribute!
Ich antworte mal in deutsch da dieses Thema fuer mein englisch zu kompliziert ist.
As you maybe know, partitions of type 0xfd (Linux raid autodetect) are scanned and automatically assembled into RAID arrays by the kernel. We noticed a strange behaviour on automatic assembling (nothing serious but a little bit confusing) and try to figure out what's the reason for it.
First of all some questions to the ones of you using SW-RAID:
- If you boot grml on a box using SW-RAID: do you expect to get a running SW-RAID setup (using the /dev/md? devices) or do you prefer to set it up and start on your own (so neither grml nor kernel touches it)?
SW-RAID setup ist zwar sehr schoen, aber auch gefaehrlich, wenn man nicht weiss wie dieses RAID vorher aussah. Mehr weiter unten dazu.
- Say you have /dev/hda1 and /dev/hdb1 as part of SW-RAID /dev/md0. Do you expect to get entries for /dev/hda1, /dev/hdb1 and /dev/md0 in your /etc/fstab? Which entries do you expect to get?
Nur die Partitionseintraege, der Rest ist gefaehrlich, s.o.
Next step: If you have a SW-RAID setup and can boot grml on the box please try to contribute via running the following steps and save output of all commands in a file. Send the file via mail to me. This would help us in debugging a lot!
############################################################################# Boot grml and check, whether the SW-RAID is running [via 'cat /proc/mdstat'].
If yes (SW-RAID is running automatically after booting grml):
Szenario: 2 RAID10 Arrays und 1x Solo RAID1 Arrays. 1. RAID10 - 2x RAID1 zusammengefasst zu RAID0 mittels raid0 Modul, 2 RAID10 - 2x RAID1 zusammengefasst zu RAID0 mittels raid10 Modul. Achso 2 U2W SCSI FP, kein S-ATA
boot grml-6-2 mit den Optionen noacpi noapm nodma lang=de SCSI Treiber aic7xxx wurde geladen
# cat /proc/mdstat
leer
cat /etc/fstab
# /etc/fstab - static file system information # # <filesystem> <mountpoint> <type> <options> <dump> <pass> /proc /proc proc defaults 0 0 none /proc/bus/usb usbfs defaults,noauto 0 0 /sys /sys sysfs auto 0 0 /dev/pts /dev/pts devpts mode=0622 0 0 /dev/fd0 /mnt/floppy auto users,noauto,exec 0 0 /dev/external /mnt/external auto users,noauto,exec,rw,uid=grml,gid=grml 0 0 /dev/external1 /mnt/external1 auto users,noauto,exec,rw,uid=grml,gid=grml 0 0 /dev/cdrom /mnt/cdrom auto users,noauto,exec,ro 0 0 /dev/dvd /mnt/dvd auto users,noauto,exec,ro 0 0 # some other examples: # /dev/hda1 /Grml ext3 dev,suid,user,noauto 0 2 # //1.2.3.4/pub /smb/pub smbfs defaults,user,noauto,uid=grml,gid=grml 0 0 # linux:/pub /beer nfs defaults 0 0 # tmpfs /tmp tmpfs size=300M 0 0 # # Warning! Please do *not* change any lines below because they are auto-generated by rebuildfstab! # If you want to disable rebuildfstab set CONFIG_FSTAB='no' in /etc/grml/autoconfig! # Added by GRML /dev/hda1 none swap defaults 0 0 # Added by GRML /dev/hda2 /mnt/hda2 ext3 noauto,nouser,dev,suid,exec 0 0 # Added by GRML /dev/sda1 none swap defaults 0 0 # Added by GRML /dev/sda5 /mnt/sda5 xfs noauto,nouser,dev,suid,exec 0 0 # Added by GRML /dev/sda6 /mnt/sda6 xfs noauto,nouser,dev,suid,exec 0 0 # Added by GRML /dev/sda7 /mnt/sda7 linux_raid_member noauto,nouser,dev,suid,exec 0 0 # Added by GRML /dev/sda8 /mnt/sda8 linux_raid_member noauto,nouser,dev,suid,exec 0 0 # Added by GRML /dev/sda9 /mnt/sda9 linux_raid_member noauto,nouser,dev,suid,exec 0 0 # Added by GRML /dev/sda10 /mnt/sda10 linux_raid_member noauto,nouser,dev,suid,exec 0 0 # Added by GRML /dev/sda11 /mnt/sda11 auto noauto,nouser,dev,suid,exec 0 0 # Added by GRML /dev/sdb1 none swap defaults 0 0 # Added by GRML /dev/sdb5 /mnt/sdb5 xfs noauto,nouser,dev,suid,exec 0 0 # Added by GRML /dev/sdb6 /mnt/sdb6 xfs noauto,nouser,dev,suid,exec 0 0 # Added by GRML /dev/sdb7 /mnt/sdb7 linux_raid_member noauto,nouser,dev,suid,exec 0 0 # Added by GRML /dev/sdb8 /mnt/sdb8 linux_raid_member noauto,nouser,dev,suid,exec 0 0 # Added by GRML /dev/sdb9 /mnt/sdb9 linux_raid_member noauto,nouser,dev,suid,exec 0 0 # Added by GRML /dev/sdb10 /mnt/sdb10 linux_raid_member noauto,nouser,dev,suid,exec 0 0 # Added by GRML /dev/sdb11 /mnt/sdb11 auto noauto,nouser,dev,suid,exec 0 0
Meine /etc/mdadm/mdadm.conf sieht so aus:
ARRAY /dev/md6 level=raid1 num-devices=2 UUID=1c9a8fc8:15322259:efedd749:bd596b5b devices=/dev/sda10,/dev/sdb10 ARRAY /dev/md5 level=raid10 num-devices=2 UUID=24ad8283:abfc8635:4267ac3d:8df9e8ca devices=/dev/md3,/dev/md4 ARRAY /dev/md3 level=raid1 num-devices=2 UUID=3a347b3a:87adc778:daa3caae:65270108 devices=/dev/sda8,/dev/sdb8 ARRAY /dev/md2 level=raid0 num-devices=2 UUID=2c09f976:de29e4e3:9114e0a2:7c3578bf devices=/dev/md0,/dev/md1 ARRAY /dev/md0 level=raid1 num-devices=2 UUID=98f931ca:50e247cd:da3155f1:26362445 devices=/dev/sda6,/dev/sdb6 ARRAY /dev/md1 level=raid1 num-devices=2 UUID=26361a58:12ec6fca:46c0665d:36cccce7 devices=/dev/sda7,/dev/sdb7 ARRAY /dev/md4 level=raid1 num-devices=2 UUID=fe11e243:73156ce0:9db9ee8d:c4c2fcd5 devices=/dev/sda9,/dev/sdb9
Fuehre ich jetzt einfach mdrun aus, habe ich jetzt nur noch 5 RAID1 Arrays. cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid5] [multipath] [raid6] [raid10] md4 : active raid1 sda10[0] sdb10[1] 292864 blocks [2/2] [UU]
md3 : active raid1 sda9[0] sdb9[1] 292864 blocks [2/2] [UU]
md2 : active raid1 sda8[0] sdb8[1] 292864 blocks [2/2] [UU]
md1 : active raid1 sda7[0] sdb7[1] 292864 blocks [2/2] [UU]
md0 : active raid1 sda6[0] sdb6[1] 292864 blocks [2/2] [UU]
mdrun scannt nur die raidautodetect Partitionen in /proc/partitions, siehe man mdrun. Ich muss also vorher wissen welche Arrays auf dem System sind. Vor einiger Zeit musste man mdrun noch 2 mal aufrufen, 1x fuer die Arrays unter dem raid10 Array und dann nochmal damit raid10 activiert wird. Das geht wohl auch noch wenn man nur 2 raidautodetect Partitionen hat.
mdrun also am besten weglassen. Besser ist folgendes mdadm -A /dev/md0 /dev/sda6 /dev/sdb6 mdadm -A /dev/md1 /dev/sda7 /dev/sdb7 mdadm -A /dev/md2 /dev/md0 /dev/md1
Dann ist auch alles korrekt. Das muss der Admin aber vorher wissen, falls es noch keine mdadm.conf gibt. cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid5] [multipath] [raid6] [raid10] md2 : active raid0 md0[0] md1[1] 585600 blocks 32k chunks
md1 : active raid1 sda7[0] sdb7[1] 292864 blocks [2/2] [UU]
md0 : active raid1 sda6[0] sdb6[1] 292864 blocks [2/2] [UU]
Ansonsten kann man ja, falls kein Root-SW-RAID, /dev/[hs]d* mounten und dann die existierende mdadm.conf benutzen. mdadm -Asc PATH_TO/mdadm.conf
Das obere Beispiel funzt auf grml aber nicht(?). Die Devices fur die Partitionen sind da nur fuer die fehlenden /dev/md* muss ich sie von Hand anlegen. Es funzt danach aber immer noch nicht. mdadm: no devices found for /dev/md3 mdadm: ...
shit funzt auf einem laufenden Sarge System auch nicht (?).
# mdadm --detail /dev/md?
ein korrektes /dev/md2
/dev/md2: Version : 00.90.03 Creation Time : Mon Feb 20 18:17:56 2006 Raid Level : raid0 Array Size : 585600 (571.97 MiB 599.65 MB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 2 Persistence : Superblock is persistent
Update Time : Mon Feb 20 18:17:56 2006 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0
Chunk Size : 32K
UUID : 5f010bc8:d294382b:5cf38fac:cd98ffa3 Events : 0.9
Number Major Minor RaidDevice State 0 9 0 0 active sync /dev/md0 1 9 1 1 active sync /dev/md1
# fdisk -l /dev/md? /dev/hd? /dev/sd? # run this for all your raid-devices and harddisk partitions
fdisk -l /dev/md2 zeigt natuerliche an das es keine Partitionstabelle gibt. fdisk -l /dev/sda zeigt folgendes:
Platte /dev/sda: 4335 MByte, 4335206400 Byte 255 Köpfe, 63 Sektoren/Spuren, 527 Zylinder Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Gerät boot. Anfang Ende Blöcke Id System /dev/sda1 1 38 305203+ fd Linux raid autodetect /dev/sda2 39 527 3927892+ 5 Erweiterte /dev/sda5 39 75 293366+ fd Linux raid autodetect /dev/sda6 75 111 292968+ fd Linux raid autodetect /dev/sda7 111 148 292968 fd Linux raid autodetect /dev/sda8 148 184 292968+ fd Linux raid autodetect /dev/sda9 184 221 292968 fd Linux raid autodetect /dev/sda10 221 257 292968+ fd Linux raid autodetect /dev/sda11 257 294 292968 fd Linux raid autodetect
und fdisk -l /dev/sdb
Platte /dev/sdb: 4569 MByte, 4569600000 Byte 255 Köpfe, 63 Sektoren/Spuren, 555 Zylinder Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Gerät boot. Anfang Ende Blöcke Id System /dev/sdb1 1 38 305203+ 82 Linux Swap / Solaris /dev/sdb2 39 555 4152802+ 5 Erweiterte /dev/sdb5 39 70 257008+ fd Linux raid autodetect /dev/sdb6 71 107 293193+ fd Linux raid autodetect /dev/sdb7 107 143 292968+ fd Linux raid autodetect /dev/sdb8 143 180 292968 fd Linux raid autodetect /dev/sdb9 180 216 292968+ fd Linux raid autodetect /dev/sdb10 216 253 292968 fd Linux raid autodetect /dev/sdb11 253 289 292968+ fd Linux raid autodetect
Frag mich nicht was das + Zeichen bei Bloecken heisst. Ich dacht zuerst das dort der Superblock liegt, aber auch nachdem loeschen des Superblocks und neu kreieren des Arrays war es die gleiche Partitionstabelle.
Auf meinem Hauptserver ist dies nicht so, da haben alle das + Zeichen bis auf die letzte Partition da ist auf allen FP gar keins.
So das wars jetzt erst einmal, ich muss das auch noch in meinem Script raid aendern, denn dort steht noch der Aufruf von mdrun 2 x hintereinander drin.
Fazit mdrun funzt nur bei einfachen RAID Arrays.
mfg Kiste
On Wed, Feb 22, 2006 at 09:35:48AM +0100, Kai Wilke wrote:
Das obere Beispiel funzt auf grml aber nicht(?). Die Devices fur die Partitionen sind da nur fuer die fehlenden /dev/md* muss ich sie von Hand anlegen.
Gut, der kernel aktiviert RAIDs nur, wenn der support dafür im kernel fix drin ist. Damit mein ich den support für den Controller, also SCSI, S-ATA, whatever. Fehlt der support für die HW so wird das RAID nicht gestartet und auch das md device nicht angelegt (Ja, dynamisches /dev hat auch seine Nachteile ;-))
Es funzt danach aber immer noch nicht.
BTW: mdadm kann die devices auch selbst anlegen, wenn du es ihm erlaubst.
mdadm: no devices found for /dev/md3 mdadm: ...
Ist das so richtig? /dev/md0-2 laufen korrekt? /dev/md3-6 laufen nicht?
md3 funktioniert nicht, obwohl es ein einfaches RAID1 ist?
shit funzt auf einem laufenden Sarge System auch nicht (?).
# mdadm --detail /dev/md?
ein korrektes /dev/md2
So das wars jetzt erst einmal, ich muss das auch noch in meinem Script raid aendern, denn dort steht noch der Aufruf von mdrun 2 x hintereinander drin.
Fazit mdrun funzt nur bei einfachen RAID Arrays.
Hab ich leider noch nie selbst getestet :-( Was mir aber aufgefallen ist: Bei deinem "echten" raid10 hast du 2 md devices. Bist dir sicher, daß das so stimmt? Bei raid10 solltest du eher 3-4 Partitionen haben.
greets Jimmy
* Andreas Gredler jimmy@grml.org [20060222 14:30]:
On Wed, Feb 22, 2006 at 09:35:48AM +0100, Kai Wilke wrote:
Das obere Beispiel funzt auf grml aber nicht(?). Die Devices fur die Partitionen sind da nur fuer die fehlenden /dev/md* muss ich sie von Hand anlegen.
Ja klar.
Gut, der kernel aktiviert RAIDs nur, wenn der support dafür im kernel fix drin ist. Damit mein ich den support für den Controller, also SCSI, S-ATA, whatever. Fehlt der support für die HW so wird das RAID nicht gestartet und auch das md device nicht angelegt (Ja, dynamisches /dev hat auch seine Nachteile ;-))
JFYI:
# cd /dev ; WRITE_ON_UDEV=1 ./MAKEDEV md
(Ist mit dem nächsten grml-tips-Update dann auch via 'grml-tips udev' anzutreffen.)
regards, -mika-
High, high ... * Andreas Gredler jimmy@grml.org schrieb am [22.02.06 14:29]:
On Wed, Feb 22, 2006 at 09:35:48AM +0100, Kai Wilke wrote:
Das obere Beispiel funzt auf grml aber nicht(?). Die Devices fur die Partitionen sind da nur fuer die fehlenden /dev/md* muss ich sie von Hand anlegen.
Gut, der kernel aktiviert RAIDs nur, wenn der support dafür im kernel fix drin ist. Damit mein ich den support für den Controller, also SCSI, S-ATA, whatever. Fehlt der support für die HW so wird das RAID nicht gestartet und auch das md device nicht angelegt (Ja, dynamisches /dev hat auch seine Nachteile ;-))
Das ist mir schon klar, das war auch nur ein Beispiel, da ich nicht in den 3h jedesmal alles von Hand starten/stoppen/anlegen... wollte. Mein HAuptserver besteht nur aus RAID Arrays.
Es funzt danach aber immer noch nicht.
BTW: mdadm kann die devices auch selbst anlegen, wenn du es ihm erlaubst.
War zu faul alles durch zu kauen. Ich habe gerade echte Probleme, Hub-Netzteil, laptop netcard,... kaputt und kein Geld.(
mdadm: no devices found for /dev/md3 mdadm: ...
Ist das so richtig? /dev/md0-2 laufen korrekt?
Die waren schon gestartet, sonst wuerde es bei md0 schon losgehen.
/dev/md3-6 laufen nicht?
Korrekt.
md3 funktioniert nicht, obwohl es ein einfaches RAID1 ist?
Doch mitttels mdrun schon, aber mdrun startet dann auch die restlichen und md5 ist wieder raid10, welches dann wieder zu einem raid1 mit sda9 sdb9 degradiert wird.
shit funzt auf einem laufenden Sarge System auch nicht (?).
# mdadm --detail /dev/md?
ein korrektes /dev/md2
So das wars jetzt erst einmal, ich muss das auch noch in meinem Script raid aendern, denn dort steht noch der Aufruf von mdrun 2 x hintereinander drin.
Fazit mdrun funzt nur bei einfachen RAID Arrays.
Hab ich leider noch nie selbst getestet :-( Was mir aber aufgefallen ist: Bei deinem "echten" raid10 hast du 2 md devices. Bist dir sicher, daß das so stimmt? Bei raid10 solltest du eher 3-4 Partitionen haben.
^^^ nur ab 4 Partitionen. Ja 2 Raid1 Arrays sind 4 Partitionen.;-)
mfg Kiste
On Wed, Feb 22, 2006 at 05:04:12PM +0100, Kai Wilke wrote:
High, high ...
- Andreas Gredler jimmy@grml.org schrieb am [22.02.06 14:29]:
BTW: mdadm kann die devices auch selbst anlegen, wenn du es ihm erlaubst.
War zu faul alles durch zu kauen. Ich habe gerade echte Probleme, Hub-Netzteil, laptop netcard,... kaputt und kein Geld.(
Oh, sorry.
md3 funktioniert nicht, obwohl es ein einfaches RAID1 ist?
Doch mitttels mdrun schon, aber mdrun startet dann auch die restlichen und md5 ist wieder raid10, welches dann wieder zu einem raid1 mit sda9 sdb9 degradiert wird.
Was war dann der Fehler mit "no devices for md3"?
Also dein raid10 läuft nur mit einem md device, statt mit den beiden? Fehlermeldung, falls es eine gibt?
BTW: Bei den neueren kernel kann man auch md devices partitionieren und muß nicht zo viele kleine RAIDs haben.
Fazit mdrun funzt nur bei einfachen RAID Arrays.
Hab ich leider noch nie selbst getestet :-( Was mir aber aufgefallen ist: Bei deinem "echten" raid10 hast du 2 md devices. Bist dir sicher, daß das so stimmt? Bei raid10 solltest du eher 3-4 Partitionen haben.
^^^ nur ab 4 Partitionen. Ja 2 Raid1 Arrays sind 4 Partitionen.;-)
Geht mit 3 auch, dann ist das eine RAID1 halt degraded. Habs gerade selbst probiert. RAID10 mit 4 Partitionen funktioniert perfekt, also kein Grund mehr ein mehrfaches RAID zu fahren.
greets Jimmy
High, high ... * Andreas Gredler jimmy@grml.org schrieb am [22.02.06 17:42]:
On Wed, Feb 22, 2006 at 05:04:12PM +0100, Kai Wilke wrote:
High, high ...
- Andreas Gredler jimmy@grml.org schrieb am [22.02.06 14:29]:
BTW: mdadm kann die devices auch selbst anlegen, wenn du es ihm erlaubst.
War zu faul alles durch zu kauen. Ich habe gerade echte Probleme, Hub-Netzteil, laptop netcard,... kaputt und kein Geld.(
Oh, sorry.
Macht nichts, ist halt der Wurm drin. Besonders beim laptop macht mich das sauer da geht bis auf FP und usb gar nichts mehr und der hat noch Garantie. Bloss die Arsches von Medion reparieren das Ding nicht. Sie meinen da ist alles heil und brauchen fuer sowas Wochen:((
md3 funktioniert nicht, obwohl es ein einfaches RAID1 ist?
Doch mitttels mdrun schon, aber mdrun startet dann auch die restlichen und md5 ist wieder raid10, welches dann wieder zu einem raid1 mit sda9 sdb9 degradiert wird.
Was war dann der Fehler mit "no devices for md3"?
Beim Befehl mdadm -Asc PATH_TO/mdadm.conf und zwar nicht nur fuer md3, sondern fuer alle Arrays die nicht activiert sind.
Also dein raid10 läuft nur mit einem md device, statt mit den beiden? Fehlermeldung, falls es eine gibt?
Es laeuft dann ueberhaupt kein raid10, alles nur raid1 Arrays, siehe meine erste mail zum Thema.
BTW: Bei den neueren kernel kann man auch md devices partitionieren und muß nicht zo viele kleine RAIDs haben.
Das ist mein Testrechner. Ich benutze doch nicht die anderen laufenden Systeme dafuer. Den kann ich wenigstens kaputt spielen:)
Aber gut zu wissen das man diese jetzt auch partitionieren kann. Ich benutze dafuer immer lvm damit ich diese, falls benoetigt auch im laufenden Betrieb vergroessern kann. Ah da faellt mir ein auf sid habe ich neulich /var vergroessert und da hat mit xfs_growfs bis auf 2 Verzeichnisse alles gekillt:(
Fazit mdrun funzt nur bei einfachen RAID Arrays.
Hab ich leider noch nie selbst getestet :-( Was mir aber aufgefallen ist: Bei deinem "echten" raid10 hast du 2 md devices. Bist dir sicher, daß das so stimmt? Bei raid10 solltest du eher 3-4 Partitionen haben.
^^^ nur ab 4 Partitionen. Ja 2 Raid1 Arrays sind 4 Partitionen.;-)
Geht mit 3 auch, dann ist das eine RAID1 halt degraded. Habs gerade selbst probiert. RAID10 mit 4 Partitionen funktioniert perfekt, also kein Grund mehr ein mehrfaches RAID zu fahren.
Alles Tests fuer mein raid Script, man muss auf alles vorbereitet sein;-) Ich hatte auch schon raid Arrays auf nur 1 FP:) Sowas ist nat. Schwachsinn, aber was macht man nicht alles wenn kein Platz da ist.
mfg Kiste
High, high ... * Kai Wilke kiste@netzworkk.de schrieb am [22.02.06 09:35]:
Ansonsten kann man ja, falls kein Root-SW-RAID, /dev/[hs]d* mounten und dann die existierende mdadm.conf benutzen. mdadm -Asc PATH_TO/mdadm.conf
Das obere Beispiel funzt auf grml aber nicht(?). Die Devices fur die Partitionen sind da nur fuer die fehlenden /dev/md* muss ich sie von Hand anlegen. Es funzt danach aber immer noch nicht. mdadm: no devices found for /dev/md3 mdadm: ...
shit funzt auf einem laufenden Sarge System auch nicht (?).
Das ganze ist ein Bug und das nicht nur auf Debian, siehe: http://lists.debian.org/debian-kernel/2005/05/msg00428.html oder google "mdadm: no devices found for /dev/md0"
Und nun sitzen wir alle inner Scheisse:))
mfg Kiste
participants (3)
-
Andreas Gredler -
Kai Wilke -
Michael Prokop