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

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?

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.

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.

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.

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é.

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,