In che modo RAID può gestire dati incoerenti?

RAID 1 e RAID 5 (e i loro fratelli 10 e 50) ottengono ridondanza dei dati rispettivamente attraverso il mirroring e il controllo di parità. Ciò consente a un array RAID di accedere ancora ai dati quando un settore su un disco (o un intero disco) diventa illeggibile. RAID 6 (o 60) utilizza un controllo aggiuntivo per consentire doppi guasti.

Ma come può un array RAID gestire dati non del tutto illeggibili, ma semplicemente incoerenti?

Se si verifica un errore tale che i dati fe su una striscia vengono modificati su un disco ma la modifica non viene propagata alle altre, l'intera striscia diventerebbe incoerente. Se in un set con mirroring un disco dice "questo bit è 0" mentre l'altro disco dice "questo bit è 1", come può un controller RAID sapere quale è giusto? Lo stesso ragionamento potrebbe essere applicato a una striscia RAID-5, con la complessità aggiunta che non si può facilmente sapere quale settore è effettivamente sbagliato nella striscia. Inoltre, RAID 6 mitiga questo problema con i suoi doppi controlli, o può ancora avere problemi a recuperare dalla corruzione dei dati quando i dati sono effettivamente leggibili ma è sbagliato da qualche parte, specialmente perché gli array RAID 6 tendono ad avere molti dischi?

Ciò potrebbe teoricamente essere risolto dai checksum, per garantire quale copia dei dati (o parità) sia quella corretta; ma un controller RAID implementa effettivamente questo tipo di checksum (che ovviamente occuperebbe spazio aggiuntivo)? O deve essere gestito a livello di sistema operativo, dove la maggior parte dei filesystem può e farà il checksum del loro contenuto? E se questo è il caso, come possono dire al controller RAID "i dati sul settore X sul disco Y sulla striscia Z sono sbagliati", quando l'approccio generale di un controller RAID è quello di astrarre il sistema operativo dal livello di archiviazione sottostante tanto quanto possibile?

RAID VOLUMES WITH PARITY STRIPE

Sui controller Areca utilizziamo (e tutti i controller RAID hardware moderni) durante un controllo di coerenza che il controller è in grado di rilevare se il danneggiamento riguarda i dati di parità, i dati fisici su disco o entrambi. La maggior parte dei controller lo fa con semplici bit di checksum per i dati di parità e i dati su disco.

Nel caso in cui i dati di parità vengano danneggiati, il controller noterà il problema quando si esegue un controllo di coerenza e rileggerà il disco fisico per i bit corretti e riscriverà la striscia di parità. Gli utenti non vedranno alcun problema perché stanno leggendo i dati su disco all'apertura dei file. Anche il salvataggio di tutto ciò che provoca la riscrittura della striscia di parità danneggiata risolverà il problema.

Se si verifica l'opposto e si capovolge un po 'i dati su disco effettivi, il controller controllerà la striscia di parità durante un controllo di coerenza per vedere se è cambiato. In questo caso il controller sovrascriverà i dati sul disco in modo che corrispondano ai dati di parità, che può confermare invariato / buono. Gli utenti riceveranno un errore CRC o un file danneggiato a seconda di quali siano i dati fino a quando non viene eseguito un controllo di coerenza e si corregge l'errore.

Poiché i dati di parità per dati specifici su disco non vengono mai archiviati sulla stessa unità dei dati effettivi, un guasto a una singola unità non dovrebbe causare problemi di corruzione dei dati. O due dischi per RAID6, ecc.

I controlli di coerenza mantengono i dati accurati il ​​più possibile e se si lasciano i dati danneggiati sul volume abbastanza a lungo, potrebbero essere scritti in dati di parità, il che significa che il file è corrotto per sempre e dovrà essere ripristinato da un backup. Se un'unità si trova in uno stato di pre-guasto in cui mostra errori durante i controlli di coerenza, sostituire immediatamente l'unità invece di attendere che il controller lo contrassegni come guasto. Eseguiamo controlli di coerenza ogni giorno su volumi più piccoli e settimanalmente su volumi più grandi.

RAID VOLUMES WITHOUT PARITY STRIPE (EX. RAID1)

Il controller / firmware del disco rigido potrebbe essere in grado di correggere il problema. Se ciò non è possibile, il controller RAID avrà difficoltà a risolvere il problema. In questo caso dovresti probabilmente leggere le unità singolarmente per recuperare i dati.

GENERALLY SPEAKING

Esegui i controlli di coerenza all'intervallo raccomandato dalla tua scheda RAID mfg. Se sei davvero preoccupato per la corruzione, puoi anche impilare un file system resiliente su un volume RAID. I moderni file system resilienti possono correggere molti di questi problemi di integrità dei dati e impilare un FS resiliente su RAID6 ti offrirebbe un eccellente uptime dei dati, senza corruzione. E anche con 2 guasti simultanei dell'unità, avresti comunque a disposizione dati di parità FS per evitare di presentare all'utente dati danneggiati.

Descrivi efficacemente la situazione, in cui un disco scrive (o legge) un errore. Il controller RAID non ha alcun modo pratico (ad es. Scrivere e rileggere ucciderebbe le prestazioni) per proteggersi da questa situazione. Deve fare affidamento sul fatto che i dischi siano in grado di rilevare questo tipo di errore e utilizzare un blocco diverso o uscire dal volume, causando un deterioramento del RAID.

Se si pensa alla situazione del singolo disco, l'unica protezione contro scritture (o letture) incoerenti è il disco stesso. RAID si basa su questo, ma non introduce una protezione aggiuntiva.

NB So per esperienza che XFS reagisce in modo abbastanza sensibile a dischi errati in un array. Quindi almeno i miei controller non di fascia bassa e il sistema operativo hanno riconosciuto ma non hanno protetto da tale incoerenza (un disco noto per essere difettoso è stato aggiunto forzatamente a un volume).