Hello Davide,
Thursday, June 15, 2006, 10:45:06 PM, you wrote:
DB> Does Linux Software RAID ensure block level consistency?
Uhm...
DB> If the system deploys a legacy Software RAID solution such as LSI
DB> megaraid and a BIOS or system utility which performs a block-level
DB> consistency check, and the consistency check reports errors while
DB> the applications detect no problem, contact the hardware vendor to
DB> check if the situation described here applies.
Si`, certo, contatta il fornitore e fagli una domanda cosi`. Poi mi
dici quanto puo` essere affidabile la risposta, ammesso che te la dia.
DB> Spero che in tal caso faccia fede /proc/mdstat
mdstat in pratica non dice nulla sullo stato reale dei dati, ma solo
su quello che il sistema crede sia lo stato generale dei dischi (tutti
e due ok oppure no). Puo` esserci una corruzione spaventosa e mdstat
non se ne accorgera` mai. Se ne accorgera` prima il driver del file
system, probabilmente. E sara` comunque troppo tardi.
Io sono diventato assolutamente paranoico sulla corruzione dei dati, e
piu` ci penso piu` mi rendo conto che nulla e` decentemente sicuro.
Non lo sono i dischi, che mi e` gia` capitato di veder riportare in
lettura dati errati senza tuttavia indicare alcun errore (cioe`,
apparentemente hai fatto una lettura "buona" e in realta` ti torna
indietro schifezza). Questo puo` succedere per un guasto
nell'elettronica o anche quando il sistema interno di rilocazione dei
settori si incasina e riloca un settore pieno ma difettoso su uno
buono ma vuoto.
Non lo sono i bridge IDE/SATA delle mainboard, che in determinate
condizioni di carico(1) possono corrompere i dati letti dal disco
anche qui senza che si verifichi un errore "evidente". (Quella che ho
chiamato la "sindrome della mucca pazza" in quanto mi e` capitata per
la prima volta su una macchina che si chiama "mucca")
Non lo e` il software RAID di Linux, che si fida del fatto che le
scritture fatte sui dischi siano buone, e che non fa MAI (a quanto ne
so) controlli del tipo "leggo lo stesso dato da tutti e due i dischi e
vedo se e` uguale". Per non parlare di MD in RAID5 e del fenomeno
della "double failure"(2)
Non lo sono le applicazioni (per dire, Postgres) che non prevedono
alcun sistema di integrity check per i dati e le strutture dei files,
per cui un database puo` corrompersi in modi spettacolari e possono
passare giorni o mesi prima di accorgersi che forse c'e` qualcosa che
non va. Pensate a un dato corrotto: non ve ne accorgerete mai. Con un
indice corrotto invece magari ve ne accorgerete dopo due settimane,
dopo che la corruzione si e` propagata nel DB in modo non
ricostruibile.
(1) chipset VIA 694 (macchina vecchiotta) con due dischi IDE, uno per
canale. Usandoci sopra MD si genera un elevato carico di accesso quasi
contemporaneo a tutti e due i canali IDE, e questo provoca corruzione
dei dati in lettura. Mettendo tutti e due i dischi sullo stesso canale
il problema sparisce, ma ovviamente le prestazioni crollano.
(2) Il raid5 di Linux ha un difetto (che probabilmente non e` solo
suo, ma si puo` estendere anche ad altre implementazioni, forse anche
nei controller "seri"). Poniamo di avere un RAID5 con molti dischi
(piu` ne hai, piu` e` alta la probabilita` che accada): ad un certo
punto uno dei dischi (diciamo il numero uno) sviluppa un settore
illeggibile in una zona inutilizzata. Questo settore illeggibile puo`
restare "nascosto" per anni, se nessuno tenta mai di leggerlo o
scriverlo. Mesi dopo (o anche due ore dopo) un altro disco (il numero
due) sviluppa un settore illeggibile in una zona usata del disco. Alla
prossima lettura, MD dichiara il disco "due" failed e continua a
lavorare con gli altri. Il sistemista cambia il disco difettoso (il
due) e lancia un rebuild.
Il rebuild per sua natura legge tutti i settori di tutti i dischi, e
mente lo fa incappa nel settore illeggibile "nascosto" del disco "uno"
che nessuno si era mai accorto di avere. MD dichiara il disco "uno"
failed perche` non riesce a leggerlo. Peccato che il disco "due" non
sia stato ancora completamente ricostruito. Hai due dischi failed, hai
perso tutto.
Questo scenario si presenta circa il 40% delle volte che si fa un
rebuild, a quanto pare, se usi 5 dischi. Meno se ne usi 3.
Mi piacerebbe sapere come fanno i controller "tosti" ad evitare questo
problema, pero` mi viene da dire che di soluzioni ce ne sarebbero
tantissime, che pero` vanno implementate:
1- leggere tutta la superficie di tutti i dischi "a tempo perso" per
scoprire gli errori nascosti fuori dalle aree usate del disco.
2- nel rebuild, tenere in linea il disco failed e aggiungere il nuovo,
poi se si verifica un errore durante il rebuild NON dichiarare failed
anche il secondo disco, ma provare a vedere se il settore che e` rotto
nel disco "due" e` leggibile nel disco "uno". Se lo e` , il rebuild
puo` procedere, chiaramente indicando che alla fine del rebuild anche
il disco "due" andra` cambiato. Se proprio l'errore fosse non
recuperabile, segnalarlo e procedere, puo` essere che si perda un solo
file e non tutto il file system (o anche nulla, se l'errore era in una
zona inutilizzata del disco)
AIUTO!!!!! I MIEI DATI SONO IN PERICOLO!!!!!
--
Fabio "Kurgan" Muzzi
La diagnosi del tecnico:
Il criceto che corre nel generatore ha avuto un infarto, stiamo aspettando
il criceto di ricambio
|