Ein weiterer Test, raid5 /dev/md127, 4 devices sd[bcde], kein Eintrag mdadm.conf.
Darauf ein ext4 mit Testdatei über das ganze raid.
Alle devices per --fail auf (F) gesetzt.
Nach Neustart sind alle (S), das raid ist ein raid0 und 'inactive'.
Herumprobiert mit '--add' + Co., aber nicht mehr von diesem Status "alle (S) / inactive" weggekommen.
Das Raid gestoppt.
Ein
neues degraded raid5 erstellt
Code: Alles auswählen
mdadm -C /dev/md128 -n 4 -l 5 /dev/sdb /dev/sdc missing /dev/sde
, die Nachfrage "raid-Data gefunden. Überschreiben?" mit 'y' bestätigt.
-> 3 'active sync', eines 'removed'.
Mount des raid5 /dev/md128 und Test der Testdatei okay. (!!!!)
Leeren der sdd und Hinzufügen
Code: Alles auswählen
cat /dev/zero > /dev/sdd
mdadm --add /dev/md128 /dev/sdd
Resync läuft durch und alle 4 'active sync', das raid5 'clean'.
Das neu erstellte raid hat natürlich eine neue UUID.
Eine Beobachtung: Nach Neustart ist das raid nicht mehr md128, sondern wieder md127(?)
-------------------------------------------------------------
EDIT Ups, nicht ausprobiert habe ich das "Verwürfeln" beim Zusammenstellen derart
'... /dev/sde missing /dev/sdb /dev/sdc'
EDIT
"Verwürfeln" ist gar nicht gut, es existiert wohl kein Automatismus, das gefundene passend zu übernehmen,
ein ext4 wird zwar noch erkannt, Mounten schlägt aber fehl.
Das "verwürfelte" kann aber nach obigem Muster wieder aufgelöst und in korrekter Reihenfolge neu angelegt werden.
Anmerkung---------------------------------------------
Bei meinen Versuchen in der VM haben gelegentlich die devices sdX gewechselt,
'mdadm -D' und mdstat waren also zu interpretieren ('blkid').
Die Benutzung auf dem unpartionierten Datenträger sdX trägt da zur Verwirrung bei.
Hilfreich wäre allein hieraus also die Benutzung von Partitionen sdXY
(bei klassischen logischen kommt eine Numerierung leider nur durch Anlage vorheriger,
dagegen unter
gpt als Partitionierungsschema kann in fdisk direkt Numer 1-128 angegeben werden), derart
/dev/sdX10
/dev/sdY11
/dev/sdZ12
...