détection et correction de la pourriture de bits avec mdadm

17

Je suis sur le point de réorganiser tous mes disques durs dans ma boîte Linux à la maison et j'aimerais utiliser raid mdadm pour la protection des données et sa flexibilité pour remodeler les baies. Cependant, avant d'utiliser mdadm pour cela, j'aimerais savoir comment il gère la pourriture des bits . Plus précisément, les types de pourriture des bits qui n'entraînent pas l'envoi de messages d'erreur de lecture irrécupérables à partir du disque dur.

Étant donné que j'utiliserai probablement au moins 21 To de disques durs sur 8 disques dans le nez et les diverses citations sur les probabilités de pannes sur les disques durs, je pense que lors d'une reconstruction à partir d'une défaillance d'un seul disque, je suis raisonnablement susceptible de rencontrer une certaine forme de pourriture des bits sur les disques restants. S'il s'agit d'une erreur de lecture irrécupérable sur l'un des lecteurs, que le lecteur le signale réellement comme une erreur, je pense que cela devrait convenir à raid6 (est-ce?). Cependant, si les données lues sur le disque sont incorrectes mais ne sont pas signalées comme telles par le disque, je ne vois pas comment cela peut être corrigé automatiquement même avec raid6. Est-ce quelque chose dont nous devons nous préoccuper? Étant donné l'article, c'est 2010 et RAID5 fonctionne toujours, et mes propres expériences réussies à la maison et au travail, les choses ne sont pas nécessairement aussi lugubres que les mots à la mode et le marketing voudraient nous le faire croire, mais je déteste devoir restaurer à partir de sauvegardes juste parce qu'un disque dur est tombé en panne.

Étant donné que les modèles d'utilisation seront, écrivez au maximum quelques fois et lisez de temps en temps, je devrai effectuer un nettoyage des données . Je vois sur le wiki archlinux les commandes mdadm pour le nettoyage des données d' un tableau comme

echo check > /sys/block/md0/md/sync_action

puis suivre les progrès

cat /proc/mdstat

Il me semble qu'il va lire tous les secteurs de tous les disques et vérifier que les données correspondent à la parité et vice-versa. Bien que je remarque que les documents mettent fortement l'accent sur le fait qu'il existe des circonstances importantes que l'opération de "vérification" ne sera pas en mesure de corriger automatiquement, mais uniquement de détecter, et qu'il appartiendra à l'utilisateur de corriger.

Quel (s) niveau (s) RAID mdadm dois-je choisir pour maximiser ma protection contre la pourriture des bits et quelles étapes de maintenance et de protection dois-je faire? Et de quoi cela ne me protégera-t-il pas?

Edit: je ne cherche pas à démarrer un RAID vs ZFS ou toute autre technologie QA. Je veux en savoir plus sur le raid mdadm. C'est aussi pourquoi je pose la question sur Unix et Linux et non sur SuperUser .

Edit: est la réponse: mdadm ne peut corriger que les URE signalés par les systèmes de disques pendant un nettoyage des données et détecter la pourriture silencieuse des bits pendant un nettoyage, mais ne peut / ne veut pas le réparer?

BeowulfNode42
la source
En ce qui concerne la protection des données, le principal avantage que je vois dans zfs est qu'il efface l'emplacement du disque des fichiers chaque fois que vous lisez un fichier. C'est pourquoi je l'ai actuellement configuré avec zfs. Mais je dois quand même effectuer des gommages complets réguliers. J'ai 2 pools zfs chacun avec 3 disques, et je veux passer à un système à 8 disques où n'importe quel lecteur peut tomber en panne et il y aura toujours 1 lecteur redondant de plus et zfs n'est pas flexible pour permettre une refonte comme ça. Depuis que je reconstruis de toute façon, je revisite mdadm.
BeowulfNode42
Jusqu'à présent, vous avez eu de la chance avec RAID5 / 6. Le fait est que nous sommes en 2013 et que RAID souffre toujours d'un trou d'écriture. Si vous perdez de l'énergie après l'écriture des données mais avant l'écriture de la parité, vous venez de corrompre vos bonnes données et il est possible qu'avec l'incohérence que votre tableau soit grillé aussi. Merci RAID5.
bahamat
Le fait est que ce que vous voulez faire est mieux fait au niveau de la couche système de fichiers. Sinon, vous auriez besoin d'un moyen pour détecter et de préférence corriger la pourriture des bits, éventuellement dans une situation de redondance réduite ou nulle, et le RAID n'est tout simplement pas adapté à cela. Non seulement il n'y a aucune garantie que vous ne vous retrouverez pas avec la pourriture de bits de toute façon (que faire si un disque tombe en panne et qu'un autre lit le bit mal sur le plateau?), Mais le RAID ordinaire n'a également aucune idée de ce qui est des données importantes et de ce qui est juste du bruit. Étant donné que ZFS ne nettoie que les données référencées , la pourriture des bits sur une partie inutilisée du disque devient un problème.
un CVn
Vraiment, vous ne pouvez pas vous attendre à superposer un système de fichiers aléatoire sur plusieurs disques (même avec redondance) pour vous protéger soudainement contre les défauts de stockage. Je ne suis pas sur une croisade sacrée pour apporter ZFS aux masses (bien que je pense que c'est une grande invention, et l'utiliser moi-même sur Linux pour pratiquement tout sauf la partition racine, qui est ext4 sur mdraid1 pour la compatibilité logicielle), mais Je reconnais également que le vôtre est l'un des types de problèmes que ZFS a été conçu dès le départ pour résoudre: détection garantie et, si possible, réparation de la corruption des données, quelle qu'en soit la cause.
un CVn
Je pense que vous devriez revoir vos exigences. Avez-vous vraiment besoin d'une protection bitrot même dans le cas où une correction d'erreur est appliquée? Savez-vous à quel point il est peu probable qu'un bitrot existe, étant donné qu'il a également été corrigé par l'ECC du disque?
homme des cavernes

Réponses:

5

Franchement, je trouve plutôt surprenant que vous rejetiez RAIDZ2 ZFS. Il semble répondre parfaitement à vos besoins, sauf qu'il ne s'agit pas de Linux MD. Je ne suis pas en croisade pour apporter ZFS aux masses, mais le simple fait est que le vôtre est l'un des types de problèmes que ZFS a été conçu de fond en comble pour résoudre. S'appuyer sur le RAID (tout RAID «normal») pour fournir une détection et une correction des erreurs, éventuellement dans une situation de redondance réduite ou nulle, semble risqué. Même dans les situations où ZFS ne peut pas corriger correctement une erreur de données, il peut au moins détecter l'erreur et vous informer qu'il y a un problème, ce qui vous permet de prendre des mesures correctives.

Vous n'avez à faire des gommages réguliers avec plein ZFS, mais il est pratique recommandée. ZFS vérifiera que les données lues sur le disque correspondent à ce qui a été écrit lors de la lecture des données, et en cas de non-concordance, soit (a) utilisez la redondance pour reconstruire les données d'origine, ou (b) signalez une erreur d'E / S à L'application. En outre, le nettoyage est une opération en ligne de faible priorité, très différente d'une vérification du système de fichiers dans la plupart des systèmes de fichiers qui peuvent être à la fois prioritaires et hors ligne. Si vous exécutez un gommage et que quelque chose d'autre que le gommage veut faire des E / S, le gommage prendra le siège arrière pour la durée. Un scrub ZFS remplace à la fois un scrub RAID et des métadonnées et données de système de fichiers vérification d'intégrité, est donc beaucoup plus approfondie que le simple nettoyage de la matrice RAID pour détecter toute pourriture de bits (ce qui ne vous dit pas si les données ont un sens, mais seulement qu'elles ont été correctement écrites par le contrôleur RAID).

La redondance ZFS (RAIDZ, mise en miroir, ...) a l'avantage que la cohérence des emplacements de disque inutilisés n'a pas besoin d'être vérifiée lors des scrubs; seules les données réelles sont vérifiées lors des scrubs, car les outils parcourent la chaîne de blocs d'allocation. C'est la même chose qu'avec un pool non redondant. Pour un RAID "normal", toutes les données (y compris les emplacements inutilisés sur le disque) doivent être vérifiées car le contrôleur RAID (matériel ou logiciel) n'a aucune idée des données réellement pertinentes.

En utilisant RAIDZ2 vdevs, deux disques constitutifs peuvent tomber en panne avant que vous ne risquiez de perdre des données en raison d'une autre panne de disque, car vous disposez de deux disques de redondance. C'est essentiellement le même que RAID6.

Dans ZFS, toutes les données, à la fois les données utilisateur et les métadonnées, sont additionnées (sauf si vous choisissez de ne pas le faire, mais cela est déconseillé), et ces sommes de contrôle sont utilisées pour confirmer que les données n'ont pas changé pour une raison quelconque. Encore une fois, si une somme de contrôle ne correspond pas à la valeur attendue, les données seront reconstruites de manière transparente ou une erreur d'E / S sera signalée. Si une erreur d'E / S est signalée ou si un nettoyage identifie un fichier corrompu, vous saurez que les données de ce fichier sont potentiellement corrompues et pouvez restaurer ce fichier spécifique à partir d'une sauvegarde; pas besoin d'une restauration complète de la baie.

Le RAID simple, même à double parité, ne vous protège pas contre des situations comme par exemple lorsqu'un disque tombe en panne et qu'un autre lit les données de manière incorrecte sur le disque. Supposons qu'un disque soit tombé en panne et qu'il y ait un seul basculement de bit n'importe où sur l'un des autres disques: tout à coup, vous avez une corruption non détectée, et à moins que vous ne soyez satisfait, vous aurez besoin d'un moyen au moins de le détecter. Le moyen d'atténuer ce risque est de faire la somme de contrôle de chaque bloc sur le disque et de s'assurer que la somme de contrôle ne peut pas être corrompue avec les données (protection contre les erreurs telles que les écritures à haute volée, les écritures orphelines, les écritures à des emplacements incorrects sur le disque, etc.), qui est exactement ce que fait ZFS tant que la somme de contrôle est activée.

Le seul véritable inconvénient est que vous ne pouvez pas facilement développer un vdev RAIDZ en y ajoutant des périphériques. Il existe des solutions de contournement pour cela, impliquant généralement des choses comme des fichiers épars en tant que périphériques dans un vdev, et très souvent appelé «je ne ferais pas cela si c'était mes données». Par conséquent, si vous optez pour une route RAIDZ (que vous optiez pour RAIDZ, RAIDZ2 ou RAIDZ3), vous devez décider à l'avance du nombre de disques que vous souhaitez dans chaque vdev. Bien que le nombre de disques dans un vdev soit fixe, vous pouvez développer un vdev en progressivement (en veillant à rester dans le seuil de redondance du vdev) en remplaçant les disques par des disques de plus grande capacité et en permettant un resilver complet.

un CVn
la source
5
Dans ma question d'origine, j'essayais d'éviter l'argument zfs vs raid car il y a beaucoup d'informations à ce sujet. Je veux des informations spécifiques sur mdadm. De plus, comme je ne lirai pas toutes les données assez souvent pour m'assurer que les données sont nettoyées régulièrement, je devrai forcer un nettoyage complet de la baie régulièrement, indépendamment de zfs ou du raid.
BeowulfNode42
@ BeowulfNode42 personnellement, je suggère d'utiliser des sommes de contrôle de couche application pour des données exceptionnellement importantes (par exemple, utilisez sha256 pour additionner vos données importantes). ZFS peut le faire par bloc, ce qui, je pense, est vraiment exagéré. Je pense que cela explique pourquoi peu de systèmes de fichiers font la somme de contrôle de leurs blocs comme le fait ZFS car IMO, c'est plus un problème de couche application à mon avis.
homme des cavernes
1
@caveman, je ne sais pas pour vous; J'aime vraiment le fait que je n'ai pas à constamment contrôler les fichiers juste pour être certain qu'ils n'ont pas été corrompus. Bien sûr, la grande majorité du temps, il n'y a pas de corruption , auquel cas aucun mal n'est fait (avec ZFS, vous obtenez votre choix d'algorithme de somme de contrôle parmi une poignée, afin que vous puissiez choisir votre point préféré le long du continuum sécurité / performances), mais Les sommes de contrôle automatisées au niveau du système de fichiers garantissent qu'il n'y a pas de corruption non corrigée car si c'est le cas, vous en serez informé, dans le cas de ZFS, en recevant une erreur d'E / S au lieu de données corrompues.
un CVn
@ MichaelKjörling non, il ne "garantit" pas (ne réduit que la probabilité d'erreurs non détectées par rapport aux vérifications sur disque uniquement, d'un montant que personne n'a encore quantifié! Donc personne ne sait vraiment à quel point la somme de contrôle de ZFS est utile :)), plus vous pouvez utiliser un simple wrapper «lecture» et «écriture» qui effectue la somme de contrôle de manière transparente pour vous. On n'a pas besoin de mettre cette fantaisie dans l'espace du noyau.
homme des cavernes
3
@caveman non, zfs n'est pas sur le sujet. Les implémentations possibles de RAID ne sont pas non plus mdadm. Je veux en savoir plus sur mdadm. J'ai déjà voté contre cette réponse autant que possible et vos commentaires sur une réponse hors sujet remplissant plus d'informations sur la réponse hors sujet n'aident pas la question d'origine.
BeowulfNode42
3

Cette réponse est le produit d'un raisonnement basé sur les différents éléments de preuve que j'ai trouvés. Je ne sais pas comment l'implémentation du noyau Linux fonctionne, car je ne suis pas un développeur du noyau et il semble y avoir une bonne quantité de désinformation absurde. Je suppose que le noyau Linux fait des choix sensés. Ma réponse devrait s'appliquer à moins que je ne me trompe.

De nombreux lecteurs utilisent des ECC (codes de correction d'erreur) pour détecter les erreurs de lecture. Si les données sont corrompues, le noyau devrait recevoir une URE (erreur de lecture irrécupérable) pour ce bloc à partir d'un lecteur prenant en charge ECC. Dans ces circonstances (et il y a une exception ci-dessous), copier des données corrompues ou vides sur de bonnes données reviendrait à de la folie. Dans cette situation, le noyau doit savoir quelles sont les bonnes données et quelles sont les mauvaises données. Selon It is 2010 et RAID5 fonctionne toujours… article:

Considérez cette alternative, que je sais être utilisée par au moins quelques fournisseurs de baies. Lorsqu'un lecteur dans un volume RAID signale un URE, le contrôleur RAID incrémente un compte et satisfait les E / S en reconstruisant le bloc à partir de la parité. Il effectue ensuite une réécriture sur le disque qui a signalé l'URE (potentiellement avec vérification) et si le secteur est mauvais, le microcode se remappera et tout ira bien.

Cependant, maintenant pour l'exception: si un lecteur ne prend pas en charge ECC, un lecteur ment à propos de la corruption de données, ou le micrologiciel est particulièrement dysfonctionnel, alors un URE peut ne pas être signalé, et des données corrompues seraient transmises au noyau. Dans le cas de données incompatibles: il semble que si vous utilisez un RAID1 à 2 disques ou un RAID5, le noyau ne peut pas savoir quelles données sont correctes, même lorsqu'il est dans un état non dégradé, car il n'y a qu'une seule parité et aucun URE n'a été signalé. Dans un RAID 1 ou un RAID6 à 3 disques, un seul bloc non marqué URE corrompu ne correspondrait pas à la parité redondante (en combinaison avec les autres blocs associés), donc une récupération automatique appropriée devrait être possible.

La morale de l'histoire est la suivante: utiliser des lecteurs avec ECC. Malheureusement, tous les lecteurs prenant en charge ECC n'annoncent pas cette fonctionnalité. D'un autre côté, soyez prudent: je connais quelqu'un qui a utilisé des SSD bon marché dans un RAID1 à 2 disques (ou un RAID10 à 2 copies). L'un des lecteurs a renvoyé des données corrompues aléatoires à chaque lecture d'un secteur particulier. Les données corrompues ont été automatiquement copiées sur les données correctes. Si le SSD utilisait des ECC et fonctionnait correctement, le noyau aurait dû prendre les mesures correctives appropriées.

sudoman
la source
1
Je pensais que tous les disques durs modernes ont une forme d'ECC interne. Qu'il soit efficace, correct ou défectueux, c'est une autre affaire. L'ECC doit être utilisé en interne dans le lecteur pour pouvoir signaler un URE. La pourriture silencieuse des bits, qui m'intéresse le plus, ne signale pas un URE même sur les lecteurs qui le prennent en charge, car ils pensent avoir les bonnes données, alors qu'ils ne le font pas.
BeowulfNode42
Par pourriture des bits, je suppose que vous entendez des bits retournant au hasard. Dans tous les cas, l'ECC est conçu pour détecter les bits inversés. Selon Wikipedia, la correction d'erreur Reed-Solomon est un format ECC commun inventé en 1960 et est toujours utilisé dans les disques Blu-Ray + HDD. Si vous découvrez que cet algorithme est extrêmement fiable, alors votre question devrait être à peu près répondue, car un matériel moderne décent, par définition, est tout aussi bon, sinon meilleur, même si vous ne connaissez pas la décence d'un matériel juste par le regarder.
sudoman
1
La pourriture des bits peut également se produire en raison d'autres problèmes, tels que lorsqu'un problème entraîne un alignement incorrect des têtes d'entraînement à l'endroit où il pense qu'il écrit et qu'il déborde sur les secteurs voisins. Il peut fixer le secteur sur lequel il avait l'intention de travailler, mais le secteur voisin sera endommagé. S'il se trouve qu'il a écrasé les données + ecc de manière à ce que l'ECC du secteur voisin signale être correct, le lecteur ne saura jamais qu'il a un problème. Beaucoup plus probable, certains logiciels malveillants demandent au lecteur d'écrire de mauvaises données, le disque dur stockera fidèlement ces mauvaises données. par exemple une mauvaise commande dd
BeowulfNode42
2

Pour la protection que vous souhaitez, j'irais avec RAID6 + la sauvegarde hors site normale dans 2 emplacements.

Personnellement, je nettoie une fois par semaine et je sauvegarde chaque nuit, chaque semaine et chaque mois en fonction de l'importance des données et de la vitesse de changement.

djsmiley2k dans l'obscurité
la source
1
mais quelles capacités de détection / correction de pourriture de bits cela offre-t-il?
BeowulfNode42
1
RAID6 avec un nettoyage fréquent offre une certaine protection contre la pourriture des bits, car la double parité crée effectivement trois versions du même bloc, de sorte qu'un "vote" peut être organisé sur la version qui convient. AFAIK, le nettoyage RAID6 dans linux dm-raid fait exactement cela, veuillez me corriger si je me trompe.
P.Péter
1
@ P.Péter Je me rends compte que les mathématiques impliquées POURRAIENT utiliser un système de vote, mais mdadm? Connaissez-vous des documents à ce sujet ou avez-vous eu une expérience personnelle qui vous a conduit à cette conclusion? Particulièrement à la lumière de la réponse d'Ethan.
BeowulfNode42
C'était il y a quelque temps, mais je me souviens vaguement d'avoir lu sur les mécanismes mdadm RAID6 avant de commenter. Désolé, pas très précis. :( Je suppose que nous pourrions utiliser un vrai expert sur mdadm ...
P.Péter
2

Je n'ai pas assez de représentant pour commenter, mais je tiens à souligner que le système mdadm sous Linux ne corrige aucune erreur. Si vous lui dites de "corriger" les erreurs lors d'un nettoyage de, disons, RAID6, s'il y a une incohérence, il la "corrigera" en supposant que les parties de données sont correctes et en recalculant la parité.

Ethan
la source
1
Cela semble plutôt improbable, à moins que je ne vous comprenne mal. Voulez-vous dire que les données des blocs corrompus sont souvent copiées sur des blocs corrects? Cela nécessiterait que le mauvais bloc ne provienne pas d'un lecteur qui prend en charge ECC (et ne signalerait donc pas d'URE), et que vous utilisez RAID5 ou 2 copie RAID1 (au lieu de RAID6 comme vous l'avez suggéré.)
sudoman
@sudoman, lors d'un scrub, si le sous-système Linux MD détecte un décalage entre les données et la parité, il suppose aveuglément que la parité est incorrecte et la réécrit en fonction des données. Il est possible d'utiliser la double parité de RAID 6 pour déterminer ce qui ne va pas, mais le sous-système Linux MD ne le fait pas.
Mark
1
Ethan, je suppose que vous n'avez aucune référence pour cette information? ou des exemples d'expérience personnelle que vous êtes prêt à partager ce dont vous vous souvenez? Étant donné les tumultes générés par ce Q, même des informations anecdotiques seraient utiles. Depuis que ce Q a été publié, j'ai eu des problèmes avec mdadm RAID1 pour le lecteur de démarrage, sur des clés USB (bon marché) lorsque l'un d'entre eux a mal tourné. Une enquête plus tard indique que la clé USB défaillante n'a pas assez ou aucune vérification d'erreur, ou qu'elle échouait simplement à écrire des données dans certains blocs et ne produisait pas d'erreur d'écriture. J'ai dû réinstaller le système d'exploitation.
BeowulfNode42
-2

peu de pourriture fud.? sûr...

Je suppose que vous devez parler à SEAGATE. (oublier? est-ce l'excuse)? les disques ont maintenant tous une correction ECC 100 bits, vous devez d'abord prouver la pourriture.
Je parie que tu ne peux pas. (c'est le truc FUD de s'inquiéter non?) comme la peur des fantômes ou le # 13? et pas fait ici. aucune preuve n'est arrivée. et pire encore aucune preuve de cause.

Définissez d'abord ce que signifie la pourriture des bits.? ouch ... HDD: ECC vérifie les données (même 1 bit) par rapport au stockage ECC 100 bits. s'il est erroné, il le corrige, s'il continue de faire échouer le moteur SMART, c'est sûr sur les disques SAS, il remplace logiquement le cluster ou le secteur par celui qui est bon. en utilisant des clusters de rechange. cela répare les dégâts. Oui, tous les disques durs grossissent du premier au dernier bout, des premiers disques IBM à MAINTENANT. mais maintenant nous effectuons nous-mêmes la réparation, lisez les livres blancs Seagate complets. sans fin là-bas, et découvrez comment fonctionne un lecteur. D'accord?

cela continue jusqu'à ce que vous soyez à court de pièces de rechange (cerveau hdd, intelligent), puis SMART hurle FIN DE VIE. (ou encore plus tôt, comme le fait HP), disons un contrôleur HP P420, il le regarde tout le temps. Le mien m'envoie même des e-mails, montrant des grappes PRES DE HORS RECHANGE. Parfois, les pièces de rechange vont beaucoup plus vite, un signe certain de malheur bientôt (10 ans, bien sûr, moins en junky sata.

J'appelle BOGUS et FUD sur bit pourriture.

Je suppose que le PC de quelqu'un a mal écrit les données, pour quelles que soient les raisons. ne pas exécuter la mémoire ECC ?? oups, les vrais serveurs ont une RAM ECC. virus infecté.? ou perte d'alimentation pendant l'écriture (pas d'UPS>?)? ou a une mauvaise mémoire.? ou ESD endommagé. Ou PSU faisant des tonnes de bruit (mauvais)

J'appelle FUD ici. Pardon,

savvy2
la source
1
Je viens de préciser que je parlais de mon système domestique, donc le matériel ECC et serveur est hors de ma fourchette de prix budgétaire. Mon laboratoire à domicile est beaucoup plus sujet à une perte de puissance inattendue, même avec ses mini-ups ou d'autres événements aléatoires, comme la tour qui tombe ou quelque chose. Il existe de nombreuses autres façons de dire à un disque dur de stocker les mauvaises données et de faire en sorte que le disque dur stocke les bits ECC pour ces données erronées. Peu m'importe comment les erreurs se sont produites, je veux qu'elles soient facilement corrigées.
BeowulfNode42