mdadm rimuove disco senza ragione al reboot
Un saluto a tutti, mi scuso per l'altra mail incompleta ma è partita a seguito
di un problema tecnico ;)
Parlo di una debian stable con kernel 3.2 da backport.
All'improvviso senza una ragione ben precisa mdadm ha iniziato a considerarmi
il terzo disco di un RAID 5 come removed a ogni reboot.
Andando a vedere non ha mai subito un fail, e non lo aggiunge nemmeno se faccio
l'assemble manuale. Con --force mi dice che forza l'event count (che era
diverso perché l'array è stato creato con 2 dischi e un missing, con il terzo
aggiunto dopo) ma continua ad avviare l'array con 2 dischi su 3 (la
maggiorparte delle persone su internet invece risolve il proprio problema così).
Il il --re-add ovviamente non riusciva senza darmi informazioni sul perché.
Il disco era in ottimo stato.
La riga dell'array in mdadm.conf mi sembra presentava i seguenti dati (ora non
sono a casa e non li ho sottomano): uuid, nome, versione metadata, bitmap.
La stringa device invece l'avevo impostata in modo che non avviasse in
automatico nessun array. Rimuovendo la riga dell'array e usando la stringa
device per l'autoassembly non è cambiato nulla.
Ogni volta che cambiavo qualcosa in mdadm.conf andavo ad aggiornare l'initramfs
(cosa che non credo fosse effettivamente necessaria).
Un --examine su tutti e 3 i dischi diceva che erano tutti "clean".
Andando a leggere i log trovo che al boot viene riconosciuto ma kickato come
"non-fresh".
Un fail e remove con successivo resync non hanno dato esito positivo. Da
nessuna parta il disco risulta "failed" per nessuna ragione.
Inoltre usavo un bitmap esterno che ho provato a rimuovere completamente o
spostare come interno. Ho ottenuto lo stesso risultato, peggiorando la
situazione perché --examine-bitmap sul file esterno e sui dischi mi diceva che
era danneggiato e in più con --bitmap=none non riuscivo più a eliminare quello
interno, che veniva correttamente disabilitato ma restava presente come
danneggiato.
Come ultimo tentativo ho aggiornato mdadm da backport e ricreato completamente
l'array (senza l'assume-clean) ancora inizialmente con 2 dischi e poi
ri-aggiungendo il terzo. Questa volta però usando metadata 1.2 e senza bitmap.
Il risultato dopo il resync è lo stesso però in questo caso se lancio un
--examine sul terzo disco trovo che non ha un superblock nonostante mdadm al
boot faccia ancora la solita procedura di riconoscerlo come parte dell'array e
kickarlo come "non-fresh".
Inoltre il disco in questione (che prima ho detto essere in ottime condizioni
perché verificata tutta la superficie e lo stato smart) ha iniziato a
presentare un "reallocated-sector-count" di circa 50.
Ipotizzando un fail dovuto a questo sono andato a controllare tutti i log
possibile ma mdadm non ha mai considerato il disco come failed (in quanto sono
solo stati riallocati alcuni settori e gli altri valori smart sono ok).
Infatti se lo aggiungo all'array (con successivo resync, quindi senza --re-add)
continua a funzionare perfettamente fino al reboot senza che mdadm si lamenti.
Lo stato smart del disco non considera alcun valore come failed e quindi non
sembra che qualche settore riallocato non sia la causa del mio problema.
Per una ulteriore verifica ho lanciato un test long con smartctl sul disco
(mentre non era attivo nell'array quindi non in uso in alcun modo dal sistema).
Ora mi trovo al lavoro e non ho modo di verificare l'esito.
Specifico che ogni volta che andavo a fare un tentativo cancellavo l'intero
superblock di mdadm (--zero-superblock) del/dei disco/i in questione.
In ogni caso temo che il problema non sia hardware perché è iniziato molto
giorni prima che il disco in questione presentasse settori riallocati. Lo stato
smart infatti l'ho sempre tenuto d'occhio da quando è iniziato sperando di
puntare il dito contro un guasto hardware e risolvere il mio problema in un attimo.
Il dmesg non ha mai presentato errori di lettura/scrittura o di vario tipo
riguardanti il disco. Che provato fuori dall'array con un filesystem qualsiasi
al suo interno funziona bene senza fare storie.
Come posso muovermi per diagnosticare il problema senza dover comprare un nuovo
disco?
Non ho intenzione di tenere quello lì, ho sempre avuto l'abitudine di
sostituire i dischi quando iniziavano presentare settori riallocati.
Però in questo caso volevo prima diagnosticare il problema (se software), poi
procedere alla soluzione e infine acquistare il disco con calma in un secondo
momento.
Di fatto non ho alcuna certezza su quale sia il problema e mi sento
completamente in alto mare.
Ho provato di tutto prima di disturbarvi (ecco perché è così lunga) ma sembra
che tutti su internet abbiano avuto problemi simili ma di natura leggermente
diversa.
Dritte su come fare una diagnosi più accurata prima di intervenire alla
sostituzione?
Grazie in anticipo per le risposte ma soprattutto per la pazienza.
--
Davide
Reply to: