mdadm a volte manca un disco dopo il riavvio

1

Su un sistema debian la mia directory home è su un array md raid1. Dopo la creazione ha funzionato bene per qualche tempo, ma una volta che la seconda unità è scomparsa dall'array.

# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda3[1]
      1843414335 blocks super 1.2 [2/1] [U_]

Quando aggiungo manualmente il disco mancante, questo viene rilevato come ricambio e l'array viene ricostruito. Fino al prossimo riavvio ...

Sono riuscito a risolverlo ricreando l'array (con le stesse partizioni). Dura diversi riavvii e ora lo stesso problema.

Entrambi i dischi sono nuovi, i controlli SMART sono ok.

Ho controllato dmesged ecco la sequenza completa "non riuscita": RAID sincronizzato buono:

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3

Al riavvio (altro dmesgqui: http://pastebin.com/q1Du95Tv ):

[ 8.175247] sda: sda1 sda2 sda3 sda4
...
[ 8.644777] md: md0 stopped.
[ 8.645248] md: bind<sda3>
[ 8.646198] md: raid1 personality registered for level 1
[ 8.646377] md/raid1:md0: active with 1 out of 2 mirrors
[ 8.646391] md0: detected capacity change from 0 to 42916118528
[ 8.646407] RAID1 conf printout:
[ 8.646409] --- wd:1 rd:2
[ 8.646411] disk 0, wo:0, o:1, dev:sda3
[ 8.648749] md0: unknown partition table
[ 8.753331] usb 4-3: new full-speed USB device number 7 using ohci-pci
[ 8.840857] sdb: sdb1 sdb2 sdb3 sdb4
[ 8.841175] sd 1:0:0:0: [sdb] Attached SCSI disk

Dopodichè:

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
2 0 0 2 removed

mdadm -Erisultato: http://pastebin.com/cp65mNQh

linux raid mdadm

— Artiom
fonte

0

Su Linux, i nomi / dev / sdXY non sono garantiti come persistenti. Cioè, per un determinato set di dischi fisici, i nodi del dispositivo non sono garantiti per apparire nello stesso ordine da un avvio all'altro.

Se hai un singolo disco, puoi essere quasi sicuro al 100% che verrà sempre visualizzato come lo stesso nodo del dispositivo (ad esempio, / dev / sda).

Se hai due dischi, puoi essere certo che verranno sempre visualizzati nello stesso ordine (in modo che "/ dev / sda all'avvio 1" sia lo stesso dispositivo fisico di "/ dev / sda all'avvio 2" per qualsiasi due stivali consecutivi).

Se hai un centinaio di dischi, la probabilità che due dischi vengano scambiati improvvisamente salta piuttosto in alto. Questo può essere il risultato di un numero qualsiasi di irregolarità, ma alla fine si riduce a che i nodi del dispositivo / dev / sdX vengono creati in ordine di rilevamento del disco e che l'ordine di rilevamento non è garantito.

Se si desidera garantire che lo stesso disco verrà sempre indicato da un determinato nome, è necessario utilizzare un identificatore permanente. Il demone con cui tutti hanno una relazione di amore-odio, udev, rende questo semplice essendo normalmente configurato per creare collegamenti simbolici nelle directory / dev / disk / by- * che indicano vari aspetti dei dischi (bus / produttore / modello / quadruplet seriale, posizione della topologia del bus, WWN , ...) sul nodo del dispositivo rilevato dal kernel. Puoi anche aggiungere regole personalizzate per creare qualsiasi schema di denominazione che preferisci. Ho colpito qualcosa di simile (ma non esattamente lo stesso) me stesso , che è stato risolto migrando ai nomi WWN.

In array di archiviazione di grandi dimensioni, questo è in realtà un problema molto reale, ed è la ragione di alcuni vantaggi piuttosto forti nell'usare sempre nomi di dispositivi persistenti quando si fa riferimento all'archiviazione.

Il problema dovrebbe scomparire (o quantomeno essere notevolmente ridotto, escludendo i problemi del disco effettivo) se si aggiungono nuovamente i dischi all'array come ad esempio / dev / disk / by-id / wwn - * - part * anziché / dev / sdXY. Ciò non dovrebbe avere alcun impatto negativo su nient'altro.

— un CVn
fonte

Un buon punto sui nomi dei dispositivi, ma nel mio caso quando ripristino il raid manualmente (l'ho fatto molte volte) trovo sempre il secondo disco con il nome sdb. Ho anche provato a catturare il momento esatto in cui l'array non è assemblato e il disco ha ancora lo stesso nome. Se non ci sarà una risposta migliore, proverò a ricreare il raid dando l'UUID del dispositivo. Tuttavia, penso di aver visto da qualche parte che md usa UUID per rilevare i dispositivi.

— Artiom,

Quindi, dopo diversi test, sembra che si sia verificato un problema di disassemblaggio più raid. L'ultima cosa che ho provato è mettere l' raid=noautodetectopzione del kernel. Ora il raid è assemblato dal sistema operativo "finale" (suppongo di sistema), ma non ha cambiato nulla. Può ancora "sopravvivere" a diversi riavvii, ma non di più. Lo stavo controllando ad ogni avvio. La denominazione del disco non è cambiata. Penso che verrà modificato solo se cambio la configurazione del disco (come aggiungere o rimuovere un disco fisico).

— Artiom,

Ho aggiornato la domanda iniziale con nuovi dettagli. Non è sicuramente un problema di denominazione del disco, ma un problema di sequenza di avvio. Ho ancora l' raid=noautodetectopzione del kernel, ma sembra che non abbia funzionato.

— Artiom,

0

Ho avuto lo stesso problema. Quello che ho trovato strano era la numerazione dei dispositivi che era 0 e 2. Ho finito per ricreare l'intera configurazione del raid.

mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1

Ora i numeri sono di nuovo 0 e 1. (secondo mdadm --detail / dev / md0)

Dopo di che ho modificato un po 'il mio file /etc/mdadm/mdadm.conf.

ARRAY /dev/md0 level=raid1 num-devices=2 devices=/dev/sda1,/dev/sdb1 UUID=<uuid of your raid setup>

Ho anche aggiunto un piccolo ritardo in /boot/cmdline.txt con rootdelay = 5

Tutti insieme sembra aver risolto il mio problema.

— Wytze
fonte