Jak przywrócić nieaktywne urządzenie RAID?


30

Po uruchomieniu moje urządzenie RAID1 ( /dev/md_d0*) czasami przechodzi w jakiś zabawny stan i nie mogę go zamontować.

* Pierwotnie stworzyłem, /dev/md0ale jakoś się zmieniło /dev/md_d0.

# mount /opt
mount: wrong fs type, bad option, bad superblock on /dev/md_d0,
       missing codepage or helper program, or other error
       (could this be the IDE device where you in fact use
       ide-scsi so that sr0 or sda or so is needed?)
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Wygląda na to, że urządzenie RAID jest nieaktywne :

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] 
                [raid4] [raid10] 
md_d0 : inactive sda4[0](S)
      241095104 blocks

# mdadm --detail /dev/md_d0
mdadm: md device /dev/md_d0 does not appear to be active.

Pytanie brzmi: jak ponownie włączyć urządzenie ( mdmadmjak się domyślam)?

(Innym razem jest w porządku (aktywny) po uruchomieniu i mogę go zamontować ręcznie bez problemów. Ale nadal nie zamontuje się automatycznie, mimo że go mam /etc/fstab:

/dev/md_d0        /opt           ext4    defaults        0       0

Więc pytanie dodatkowe: co powinienem zrobić, aby urządzenie RAID automatycznie montowało się /optpodczas uruchamiania? )

To jest stacja robocza Ubuntu 9.10. Informacje podstawowe o mojej konfiguracji RAID w tym pytaniu .

Edycja : Mój /etc/mdadm/mdadm.confwygląda tak. Nigdy nie dotknąłem tego pliku, przynajmniej ręcznie.

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR <my mail address>

# definitions of existing MD arrays

# This file was auto-generated on Wed, 27 Jan 2010 17:14:36 +0200

W /proc/partitionsostatnim wpisie jest md_d0przynajmniej teraz, po ponownym uruchomieniu, kiedy urządzenie znów jest aktywne. (Nie jestem pewien, czy będzie tak samo, gdy będzie nieaktywny).

Rozwiązanie : jak zasugerował Jimmy Hedman , wziąłem wyniki mdadm --examine --scan:

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=de8fbd92[...]

i dodał to /etc/mdadm/mdadm.conf, co wydaje się naprawiać główny problem. Po zmianie /etc/fstabna używanie /dev/md0ponownie (zamiast /dev/md_d0) urządzenie RAID również zostaje automatycznie zamontowane!

Odpowiedzi:


25

W przypadku pytania bonusowego:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

2
Ok, mdadm --examine --scanwyprodukowano ARRAY /dev/md0 level=raid1 num-devices=2 UUID=...(Uwaga md0 zamiast md_d0!) Umieściłem to w pliku mdadm.conf (ręcznie, ponieważ był jakiś problem z sudo i >>(„odmowa uprawnień”), a sudo jest wymagane), a także zaktualizowałem fstab do użycia md0 (nie md_d0) ponownie. Teraz wydaje mi się, że nie mam już problemu z „nieaktywnością”, a urządzenie RAID montuje się automatycznie przy / opt po uruchomieniu. Więc dziękuję!
Jonik

3
Powodem, dla którego masz problemy, sudo ... >> mdadm.confjest to, że powłoka otwiera przekierowane pliki przed uruchomieniem sudo. Polecenie su -c '.... >> mdadm.conf'powinno działać.
Mei

10

Odkryłem, że muszę ręcznie dodać tablicę /etc/mdadm/mdadm.conf, aby Linux mógł ją zamontować przy ponownym uruchomieniu. W przeciwnym razie otrzymam dokładnie to, co masz - md_d1urządzenia, które są nieaktywne itp.

Plik conf powinien wyglądać jak poniżej - tzn. Jedna ARRAYlinia dla każdego urządzenia MD. W moim przypadku brakowało nowych tablic w tym pliku, ale jeśli masz je na liście, prawdopodobnie nie jest to rozwiązanie twojego problemu.

# definitions of existing MD arrays
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Dodaj jedną tablicę na urządzenie md i dodaj je po komentarzu zawartym powyżej lub, jeśli takiego komentarza nie ma, na końcu pliku. UUID można uzyskać, wykonując sudo mdadm -E --scan:

$ sudo mdadm -E --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Jak widać, możesz po prostu skopiować wyniki z wyniku skanowania do pliku.

Pracuję na Ubuntu Desktop 10.04 LTS i, o ile pamiętam, to zachowanie różni się od wersji serwerowej Ubuntu, jednak tak dawno temu stworzyłem moje urządzenia MD na serwerze, mogę się mylić. Być może właśnie przegapiłem jakąś opcję.

W każdym razie dodanie tablicy do pliku conf wydaje się załatwić sprawę. Od lat prowadzę powyższy rajd 1 i rajd 5 bez żadnych problemów.


1
Więc zasadniczo mówisz to samo, co obecnie akceptowana odpowiedź, tylko bardziej słownie? :) Mimo to +1 fajny pierwszy post.
Jonik

7

Ostrzeżenie: przede wszystkim pozwól mi powiedzieć, że poniższe (ze względu na użycie „--force”) wydaje mi się ryzykowne, a jeśli masz nieodwracalne dane, zaleciłbym wykonanie kopii partycji, zanim zaczniesz próbować którejkolwiek z rzeczy poniżej. Jednak zadziałało to dla mnie.

Miałem ten sam problem z tablicą wyświetlaną jako nieaktywną i nic, co zrobiłem, w tym „mdadm --examine --scan> /etc/mdadm.conf”, jak sugerują inni tutaj, wcale nie pomogło.

W moim przypadku, kiedy próbował uruchomić macierz RAID-5 po wymianie dysku, mówił, że jest brudny (przez dmesg):

md/raid:md2: not clean -- starting background reconstruction
md/raid:md2: device sda4 operational as raid disk 0
md/raid:md2: device sdd4 operational as raid disk 3
md/raid:md2: device sdc4 operational as raid disk 2
md/raid:md2: device sde4 operational as raid disk 4
md/raid:md2: allocated 5334kB
md/raid:md2: cannot start dirty degraded array.

Powoduje, że wyświetla się jako nieaktywny w /proc/mdstat:

md2 : inactive sda4[0] sdd4[3] sdc4[2] sde4[5]
      3888504544 blocks super 1.2

Odkryłem, że na wszystkich urządzeniach były takie same zdarzenia, z wyjątkiem dysku, który wymieniłem ( /dev/sdb4):

[root@nfs1 sr]# mdadm -E /dev/sd*4 | grep Event
mdadm: No md superblock detected on /dev/sdb4.
         Events : 8448
         Events : 8448
         Events : 8448
         Events : 8448

Jednak szczegóły tablicy pokazały, że ma 4 z 5 dostępnych urządzeń:

[root@nfs1 sr]# mdadm --detail /dev/md2
/dev/md2:
[...]
   Raid Devices : 5
  Total Devices : 4
[...]
 Active Devices : 4
Working Devices : 4
[...]
    Number   Major   Minor   RaidDevice State
       0       8        4        0      inactive dirty  /dev/sda4
       2       8       36        2      inactive dirty  /dev/sdc4
       3       8       52        3      inactive dirty  /dev/sdd4
       5       8       68        4      inactive dirty  /dev/sde4

(Powyższe pochodzi z pamięci w kolumnie „Stan”, nie mogę go znaleźć w buforze przewijania).

Byłem w stanie rozwiązać ten problem, zatrzymując tablicę, a następnie ponownie ją składając:

mdadm --stop /dev/md2
mdadm -A --force /dev/md2 /dev/sd[acde]4

W tym momencie tablica była gotowa, działała z 4 z 5 urządzeń, i mogłem dodać urządzenie zastępcze i przebudowuje się. Jestem w stanie uzyskać dostęp do systemu plików bez żadnego problemu.


4

Miałem problemy z Ubuntu 10.04, gdzie błąd w FStab uniemożliwił uruchomienie serwera.

Uruchomiłem to polecenie, jak wspomniano w powyższych rozwiązaniach:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Spowoduje to dodanie wyników z „mdadm --examine --scan” do „/etc/mdadm/mdadm.conf”

W moim przypadku było to:

ARRAY /dev/md/0 metadata=1.2 UUID=2660925e:6d2c43a7:4b95519e:b6d110e7 name=localhost:0

To jest fakeraid 0. Moje polecenie w / etc / fstab do automatycznego montowania to:

/dev/md0 /home/shared/BigDrive ext3 defaults,nobootwait,nofail 0 0

Ważne jest tutaj to, że masz „nobootwait” i „nofail”. Nobootwait pominie wszelkie komunikaty systemowe, które uniemożliwiają uruchomienie komputera. W moim przypadku było to na zdalnym serwerze, więc było to niezbędne.

Mam nadzieję, że to pomoże niektórym ludziom.


Właśnie to dla mnie zrobiło. Mam dyski RAID podłączone za pomocą karty PCI Express SATA, więc domyślam się, że w czasie uruchamiania system nie mógł ich jeszcze zobaczyć.
Michael Robinson

2

Możesz aktywować urządzenie MD za pomocą

mdadm -A /dev/md_d0

Przypuszczam, że jakiś skrypt startowy uruchamia się zbyt wcześnie, zanim zostanie wykryty jeden z członków RAID lub jakiś podobny problem. Jako szybkie i nieprzyzwoite obejście, powinieneś być w stanie dodać tę linię do /etc/rc.local:

mdadm -A /dev/md_d0 && mount /dev/md_d0

Edycja: najwyraźniej twój /etc/mdadm/mdadm.conf nadal zawiera starą nazwę konfiguracji. Edytuj ten plik i zamień wystąpienia md0 na md_d0.


Ok, w tych przypadkach, gdy urządzenie jest aktywne po ponownym uruchomieniu komputera, tylko mount /dev/md_d0w /etc/rc.localdziała prawidłowo. mdadm -A /dev/md_d0z drugiej strony ten komunikat o błędzie nie działa w obu przypadkach (więc nie mogłem go użyć przed tym &&operatorem). W każdym razie połowa problemu wydaje się rozwiązana, więc +1 za to.
Jonik

W rzeczywistości plik mdadm.conf nie zawiera żadnej nazwy konfiguracji, przynajmniej bezpośrednio (odnosi się to /proc/partitionsjednak); zobacz edytowane pytanie. Nigdy nie dotknąłem mdadm.conf - jakie narzędzie to automatycznie generuje?
Jonik

Dla przypomnienia usunąłem /etc/rc.localobejście, ponieważ wydaje się, że wszystko działa poprawnie: superuser.com/questions/117824/… :)
przypomnienia Jonik 10.10

2

Miałem podobny problem ... mój serwer nie zamontował md2 po tym, jak rozwinąłem powiązane partycje urządzeń. Po przeczytaniu tego wątku stwierdziłem, że urządzenie RAID md2 ma nowy identyfikator UUID, a urządzenie próbuje użyć starego.

Zgodnie z sugestią ... używając wyjścia 'md2' z

mdadm --examine --scan

Zredagowałem /etc/mdadm/mdadm.confi zastąpiłem stary wiersz UUID jednym wyjściem z powyższego polecenia i mój problem zniknął.


2

Kiedy udajesz, że coś z /dev/md[012346789}tym robisz , idzie do /dev/md{126,127...}. /dev/md0kontynuuje montowanie na /dev/md126lub /dev/md127musisz:

umount /dev/md127 lub umount /dev/md126.

Jest to tymczasowe, aby umożliwić wykonywanie poleceń i niektórych aplikacji bez zatrzymywania systemu.


1

md_d0 : inactive sda4[0](S)wygląda źle dla macierzy RAID1. Wydaje się sugerować, że tablica nie ma aktywnych urządzeń i jedno urządzenie zapasowe (wskazane przez (S), zobaczysz (F) tam dla uszkodzonego urządzenia i nic dla OK / aktywnego urządzenia) - dla macierzy RAID1, która nie jest nie działa zdegradowane, powinny być co najmniej dwa urządzenia OK / aktywne (a dla zdegradowanej macierzy, co najmniej jedno urządzenie OK / aktywne) i nie można aktywować macierzy RAID1 bez żadnych nieudanych nie-zapasowych urządzeń (jako części zamiennych nie zawierają kopii danych, dopóki nie zostaną uaktywnione, gdy inny dysk ulegnie awarii). Jeśli dobrze odczytam to /proc/mdstatwyjście, nie będziesz w stanie aktywować tablicy w jej obecnym stanie.

Czy masz jakieś dyski fizyczne w maszynie, które nie zostały uruchomione? Czy wyświetla ls /dev/sd*listę wszystkich dysków i partycji, których normalnie można oczekiwać na tym komputerze?


Wygląda na to, że nie jestem w stanie odtworzyć nieaktywnej sytuacji, po zastosowaniu się do wskazówek zawartych w odpowiedzi Jimmy'ego (wydaje się, że tak też jest po kilku restartach) ... Co jest miłe :) W każdym razie dzięki!
Jonik

Przyniosłem pytanie o ten stan na listę mailingową Linux RAID i otrzymałem następującą odpowiedź: spinics.net/lists/raid/msg61352.html
nh2

Jak właśnie napisałem tutaj , echo active > /sys/block/md0/md/array_statepracowałem dla siebie, sprawiając, że mój RAID pojawił się ponownie jako RAID1 z brakującym dyskiem zamiast RAID0 z zapasowym.
nh2

1

Prosty sposób na uruchomienie tablicy przy założeniu, że nie ma problemu ze sprzętem i masz wystarczającą liczbę napędów / partycji do uruchomienia tablicy, jest następujący:

md20 : inactive sdf1[2](S)
      732442488 blocks super 1.2

 sudo mdadm --manage /dev/md20  --run

Może być tak, że z jakiegokolwiek powodu tablica jest w porządku, ale coś uniemożliwiło jej uruchomienie lub budowę. W moim przypadku było to spowodowane tym, że mdadm nie wiedział, że pierwotna nazwa macierzy to md127 i wszystkie dyski zostały odłączone dla tej macierzy. Podczas ponownej instalacji musiałem ręcznie złożyć (prawdopodobnie błąd, w którym mdadm myślał, że tablica jest już aktywna z powodu starej starej tablicy offline).

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.