Ma compréhension est que les disques durs et SSD implémentent une correction d'erreur de base à l'intérieur du lecteur, et la plupart des configurations RAID, par exemple mdadm, en dépendront pour décider quand un lecteur n'a pas réussi à corriger une erreur et doit être mis hors ligne. Cependant, cela dépend de la précision du stockage à 100% dans son diagnostic d'erreur. Ce n'est pas le cas, et une configuration courante comme un miroir RAID-1 à deux disques sera vulnérable: supposons que certains bits sur un disque soient corrompus en silence et que le disque ne signale pas d'erreur de lecture. Ainsi, des systèmes de fichiers tels que btrfs et ZFS implémentent leurs propres sommes de contrôle, afin de ne pas faire confiance aux firmwares de lecteur buggy, aux câbles SATA glitchy, etc.
De même, la RAM peut également avoir des problèmes de fiabilité et nous avons donc de la RAM ECC pour résoudre ce problème.
Ma question est la suivante : quelle est la manière canonique de protéger le fichier d'échange Linux contre la corruption silencieuse / la pourriture de bits non détectée par le micrologiciel du lecteur sur une configuration à deux disques (c'est-à-dire en utilisant les pilotes du noyau principal)? Il me semble qu'une configuration qui manque ici de protection de bout en bout (comme celle fournie par btrfs) annule quelque peu la tranquillité d'esprit apportée par la RAM ECC. Pourtant, je ne peux pas penser à une bonne façon:
- btrfs ne prend pas du tout en charge les fichiers d'échange. Vous pouvez configurer un périphérique de boucle à partir d'un fichier btrfs et effectuer un échange à ce sujet. Mais cela a des problèmes:
- Les écritures aléatoires ne fonctionnent pas bien: https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
- La suggestion de désactiver la copie sur écriture désactivera également la somme de contrôle, ce qui ira à l'encontre de tout l'intérêt de cet exercice. Leur hypothèse est que le fichier de données possède ses propres protections internes.
- ZFS sur Linux permet d'utiliser un ZVOL comme échange, ce qui, je suppose, pourrait fonctionner: http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap - cependant, d'après ma lecture, ZFS demande normalement de la mémoire et le fait fonctionner dans un échange -la seule application sonne comme du travail pour le comprendre. Je pense que ce n'est pas mon premier choix. Pourquoi vous devriez utiliser un module de noyau hors arbre juste pour avoir un échange fiable me dépasse - il y a sûrement un moyen d'accomplir cela avec la plupart des distributions / noyaux Linux modernes de nos jours?
- Il y avait en fait un fil sur une liste de diffusion du noyau Linux avec des correctifs pour activer les sommes de contrôle dans le gestionnaire de mémoire lui-même, pour exactement les raisons que j'explique dans cette question: http://thread.gmane.org/gmane.linux.kernel/989246 - malheureusement, pour autant que je sache, le patch est mort et n'est jamais parvenu en amont pour des raisons que je ne connais pas. Dommage, cela sonnait comme une fonctionnalité intéressante. D'un autre côté, si vous mettez l'échange sur un RAID-1 - si la corruption dépasse la capacité de la somme de contrôle à réparer, vous voudriez que le gestionnaire de mémoire essaie de lire sur l'autre disque avant de paniquer ou autre chose, ce qui est probablement en dehors de ce que doit faire un gestionnaire de mémoire.
En résumé:
- La RAM a ECC pour corriger les erreurs
- Les fichiers sur le stockage permanent ont des btrfs pour corriger les erreurs
- Swap a ??? <--- c'est ma question
la source
Réponses:
Nous faisons confiance à l'intégrité des données extraites du swap car le matériel de stockage a des sommes de contrôle, des CRC, etc.
Dans l'un des commentaires ci-dessus, vous dites:
"Il" signifie ici les sommes de contrôle du disque.
C'est vrai, mais SATA utilise des CRC 32 bits pour les commandes et les données. Ainsi, vous avez 1 chance sur 4 milliards de corrompre indétectablement les données entre le disque et le contrôleur SATA. Cela signifie qu'une source d'erreur continue pourrait introduire une erreur aussi souvent que tous les 125 Mio transférés, mais une source d'erreur aléatoire rare comme les rayons cosmiques provoquerait des erreurs indétectables à un rythme extrêmement faible.
Sachez également que si vous avez une source qui provoque une erreur non détectée à un taux proche de 1 pour 125 Mio transférés, les performances seront terribles en raison du nombre élevé d' erreurs détectées nécessitant un nouveau transfert. La surveillance et la journalisation vous alerteront probablement à temps du problème pour éviter une corruption non détectée.
En ce qui concerne les sommes de contrôle du support de stockage, chaque disque SATA (et avant lui, PATA) utilise des sommes de contrôle par secteur. L'une des caractéristiques des disques durs «d'entreprise» est la présence de secteurs plus importants protégés par des fonctionnalités supplémentaires d'intégrité des données , ce qui réduit considérablement les risques d'erreur non détectée.
Sans de telles mesures, le pool de secteurs de rechange dans chaque disque dur ne servirait à rien : le lecteur lui-même ne pourrait pas détecter un secteur défectueux, il ne pourrait donc jamais échanger de nouveaux secteurs.
Dans un autre commentaire, vous demandez:
D'une manière générale, nous ne demandons pas au swap de stocker des données à long terme. La limite du stockage d'échange est la disponibilité du système , et la plupart des données dans l'échange ne durent pas aussi longtemps, car la plupart des données qui transitent par le système de mémoire virtuelle de votre système appartiennent à des processus de durée de vie beaucoup plus courte.
En plus de cela, les temps de disponibilité se sont généralement raccourcis au fil des ans, avec l'augmentation de la fréquence du noyau et des
libcmises à jour, la virtualisation, les architectures cloud, etc.De plus, la plupart des données de swap sont inutilisées de manière inhérente dans un système bien géré, qui ne s'exécute pas lui-même hors de la RAM principale. Dans un tel système, les seules choses qui finissent par être échangées sont des pages que le programme n'utilise pas souvent, voire jamais. C'est plus courant que vous ne le pensez. La plupart des bibliothèques dynamiques que vos programmes lient pour avoir des routines que votre programme n'utilise pas, mais elles devaient être chargées dans la RAM par l' éditeur de liens dynamiques . Lorsque le système d' exploitation voit que vous n'utilisez pas tout le texte du programme dans la bibliothèque, il permute dehors, faire de la place pour le code et les données que vos programmes sont utilisent. Si de telles pages de mémoire échangées sont corrompues, qui le saura jamais?
Comparez cela avec ZFS, où nous nous attendons à ce que les données soient stockées de manière durable et persistante, de sorte qu'elles durent non seulement au-delà de la disponibilité actuelle du système, mais également au-delà de la durée de vie des périphériques de stockage individuels qui composent le système de stockage. ZFS et autres résolvent un problème avec une échelle de temps d'environ deux ordres de grandeur plus longue que le problème résolu par swap. Nous avons donc des exigences de détection de corruption beaucoup plus élevées pour ZFS que pour Linux swap.
ZFS et autres diffèrent du swap d'une autre manière clé ici: nous ne faisons pas de swap RAID ensemble. Lorsque plusieurs périphériques de swap sont utilisés sur une seule machine, il s'agit d'un schéma JBOD , pas comme RAID-0 ou supérieur. (par exemple, le schéma de fichiers d'échange enchaînés de macOS , Linux
swapon, etc.) Étant donné que les périphériques d'échange sont indépendants, plutôt qu'interdépendants comme avec RAID, nous n'avons pas besoin d'une somme de contrôle étendue car le remplacement d'un périphérique d'échange n'implique pas de regarder d'autres périphériques d'échange interdépendants pour les données qui devraient aller sur l'appareil de remplacement. En termes ZFS, nous ne resilverons pas les périphériques d'échange de copies redondantes sur d'autres périphériques de stockage.Tout cela signifie que vous devez utiliser un appareil d'échange fiable. J'ai utilisé une fois un boîtier de disque dur USB externe de 20 $ pour sauver un pool ZFS en difficulté, seulement pour découvrir que le boîtier n'était pas fiable, introduisant des erreurs propres dans le processus. Le solide total de contrôle de ZFS m'a sauvé ici. Vous ne pouvez pas vous en tirer avec un tel traitement cavalier des supports de stockage avec un fichier d'échange. Si le périphérique d'échange est en train de mourir et approche ainsi du pire des cas où il pourrait injecter une erreur indétectable tous les 125 Mio transférés, il vous suffit de le remplacer dès que possible.
Le sens général de la paranoïa dans cette question revient à un exemple du problème des généraux byzantins . Lisez à ce sujet, réfléchissez à la date de 1982 sur l'article académique décrivant le problème au monde de l'informatique, puis décidez si, en 2019, vous avez de nouvelles idées à ajouter à ce problème. Et sinon, vous utiliserez peut- être la technologie conçue par trois décennies de diplômés CS qui connaissent tous le problème des généraux byzantins.
C'est un terrain bien foulé. Vous ne pouvez probablement pas trouver une idée, une objection ou une solution qui n'a pas déjà été discutée à mort dans les revues d'informatique.
SATA n'est certainement pas totalement fiable, mais à moins que vous ne rejoigniez le monde universitaire ou l'une des équipes de développement du noyau, vous ne serez pas en mesure d'ajouter de manière significative à l'état de l'art ici. Ces problèmes sont déjà bien en main, comme vous l'avez déjà noté: ZFS, btrfs, ReFS ... En tant qu'utilisateur du système d'exploitation, vous devez simplement avoir confiance que les créateurs du système d'exploitation s'occupent de ces problèmes pour vous, car ils savent également sur les généraux byzantins.
Il n'est actuellement pas pratique de placer votre fichier d'échange au-dessus de ZFS ou de Btrfs, mais si ce qui précède ne vous rassure pas, vous pouvez au moins le placer sur xfs ou ext4. Ce serait mieux que d'utiliser une partition de swap dédiée.
la source
intégrité-dm
Voir: Documentation / device-mapper / dm-Integrity.txt
dm-integrityserait normalement utilisé en mode journalisation. Dans le cas du swap, vous pouvez vous passer de la journalisation. Cela pourrait réduire considérablement les frais généraux de performance. Je ne sais pas si vous auriez besoin de reformater la partition de permutation sur l'intégrité à chaque démarrage, pour éviter d'attraper des erreurs après un arrêt impur.Dans l' annonce initiale de
dm-integrity, l'auteur indique plutôt une préférence pour "la protection de l'intégrité des données au niveau supérieur". Dans le cas du swap, cela ouvrirait la possibilité de stocker les sommes de contrôle dans la RAM. Cependant, cette option nécessiterait à la fois des modifications non triviales du code d'échange actuel et augmenterait l'utilisation de la mémoire. (Le code actuel suit les swaps efficacement en utilisant des étendues, pas des pages / secteurs individuels).DIF / DIX?
Le support DIX a été ajouté par Oracle dans Linux 2.6.27 (2008).
L'utilisation de DIX offre-t-elle une intégrité de bout en bout?
Vous pouvez consulter votre fournisseur. Je ne sais pas comment vous pourriez dire s'ils mentent à ce sujet.
DIX est requis pour protéger les données en vol entre l'OS (système d'exploitation) et le HBA .
Le DIF à lui seul augmente la protection des données en vol entre le HBA et le périphérique de stockage . (Voir aussi: présentation avec quelques chiffres sur la différence de taux d'erreur ).
Précisément parce que la somme de contrôle dans le champ de garde est standardisée, il est techniquement possible d'implémenter des commandes DIX sans fournir de protection pour les données au repos. Demandez au HBA (ou au périphérique de stockage) de régénérer la somme de contrôle au moment de la lecture. Cette perspective a été rendue très claire par le projet DIX original.
L'un de leurs premiers articles sur DIX mentionne la possibilité d'utiliser DIX entre OS et HBA même lorsque le lecteur ne prend pas en charge DIF.
Une mendacité totale est relativement peu probable dans des contextes "d'entreprise" où DIX est actuellement utilisé; les gens le remarqueraient. De plus, DIF était basé sur du matériel existant qui pouvait être formaté avec des secteurs de 520 octets. Le protocole d'utilisation de DIF exige que vous reformatiez d'abord le lecteur, voir par exemple la
sg_formatcommande.Ce qui est plus probable, c'est une mise en œuvre qui ne suit pas le véritable principe de bout en bout . Pour donner un exemple, un fournisseur est mentionné qui prend en charge une option de somme de contrôle plus faible pour DIX pour économiser les cycles du processeur, qui est ensuite remplacée par une somme de contrôle plus forte plus bas dans la pile. C'est utile, mais ce n'est pas une protection complète de bout en bout.
Alternativement, un système d'exploitation pourrait générer ses propres sommes de contrôle et les stocker dans l'espace de balise d'application. Cependant, il n'y a pas de support pour cela dans Linux actuel (v4.20) . Le commentaire, écrit en 2014, suggère que cela pourrait être dû au fait que "très peu de périphériques de stockage permettent réellement d'utiliser l'espace de balise d'application". (Je ne suis pas certain que cela se réfère au périphérique de stockage lui-même, au HBA ou aux deux).
Quels types de périphériques DIX sont disponibles et fonctionnent avec Linux?
Wikipedia me dit que DIF est standardisé dans NVMe 1.2.1. Pour les adaptateurs de bus hôte SCSI, il semble un peu difficile de déterminer si nous n'avons pas de norme à indiquer. Pour le moment, il pourrait être plus précis de parler du support "Linux DIX" :-). Il existe des appareils disponibles:
Tout le matériel mentionné dans les notes de mise à jour de RHEL 7.5 est Fibre Channel.
Je ne connais pas ce marché. Il semble que DIX pourrait devenir plus largement disponible sur les serveurs à l'avenir. Je ne connais aucune raison pour laquelle il deviendrait disponible pour les disques SATA grand public - pour autant que je sache, il n'y a même pas de norme de facto pour le format de commande. Je serai intéressé de voir s'il sera disponible plus largement sur NVMe.
la source
Le swap n'est toujours pas protégé sous Linux (mais voir UPD).
Bien sûr, il y a ZFS sur Linux qui est capable d'être un stockage de swap mais il y a toujours un verrouillage dans certaines circonstances - révoquant ainsi efficacement cette option.
Btrfs ne peut toujours pas gérer les fichiers d'échange . Ils mentionnent l'utilisation possible du bouclage bien qu'il soit noté comme étant de piètre performance. Il y a une indication peu claire que Linux 5 pourrait enfin l'avoir (?)…
Les correctifs pour protéger le swap conventionnel lui-même avec des sommes de contrôle n'ont pas été généralisés.
Donc, tout-en-un: non. Linux a encore un écart.
UPD. : Comme le souligne @ sourcejedi , il existe un outil tel que l'intégrité-dm. Le noyau Linux depuis la version 4.12 a obtenu la cible du mappeur de périphériques qui peut être utilisée pour fournir des sommes de contrôle à tous les périphériques de bloc généraux et ceux qui sont destinés à l'échange ne font pas exception. L'outillage n'est pas largement incorporé dans les principales distributions et la plupart d'entre eux n'ont aucun support dans le sous-système udev, mais cela devrait finalement changer. Lorsqu'il est associé à un fournisseur de redondance, par exemple placé sur un dessus de MD aka Linux Software RAID, il devrait être possible non seulement de détecter la pourriture des bits, mais également de rediriger la demande d'E / S vers des données saines, car l'intégrité dm indique qu'il existe un problème et MD devrait le gérer.
la source
Je ne pense pas qu'il existe une voie "canonique", donc voici mon opinion personnelle.
Ayant surveillé l'avancée des btrfs du point de vue d'un utilisateur potentiel, je dois dire que cela me semble encore quelque peu obscur. Il y a des fonctionnalités qui sont matures et prêtes à être utilisées en production, et il y a des fonctionnalités qui semblent immatures et dangereuses à utiliser.
Personnellement, je n'ai pas le temps de décider quelle fonctionnalité utiliser et laquelle ne pas, laissez de côté le temps dont j'avais besoin pour comprendre comment désactiver ou activer ces fonctionnalités.
En revanche, ZFS est solide comme le roc et mature (IMHO). Donc, pour répondre à votre question, j'utiliserais ZFS (au fait, il ne consomme pas beaucoup de mémoire - voir ci-dessous).
Mais pour vous, btrfs pourrait être le bon choix puisque vous l'utilisez déjà (si je vous ai bien compris), et l'un des commentaires ci-dessus montre comment l'utiliser pour le swap.
Par pur hasard, j'ai mis des serveurs Linux sur ZFS au cours des derniers jours, y compris à chaque fois le système de fichiers racine et le swap. Avant de faire cela, j'ai fait des recherches très approfondies, ce qui m'a pris plusieurs jours. Un bref résumé de ce que j'ai appris:
Consommation de mémoire de ZFS
Il existe un malentendu commun concernant la consommation de mémoire de ZFS. ZFS ne consomme généralement pas beaucoup de mémoire; en fait, il fonctionne avec des To de stockage sur des machines avec 2 Go de RAM. Seulement si vous utilisez la déduplication (désactivée par défaut), cela nécessite beaucoup, beaucoup de RAM.
Détection / correction d'erreurs matérielles
Que les SATA, PATA, RAID ou autres mécanismes de détection / correction d'erreurs soient suffisants pour l'intégrité des données est un sujet qui provoque des discussions sans fin et même des guerres de flamme à tous les endroits sur le net. En théorie, un périphérique de stockage matériel devrait signaler (et éventuellement corriger) toute erreur qu'il rencontre, et le matériel de transmission de données à tous les niveaux (chipset, mémoire, etc.) devrait également le faire.
Eh bien, ils ne le font pas dans tous les cas, ou ils réagissent de manière surprenante aux erreurs. À titre d'exemple, prenons une configuration RAID5 typique. Normalement, si un disque a un problème, il le signalera au RAID qui à son tour construit les données à lire à partir des autres disques et les transmet, mais les réécrit également sur le disque défectueux (qui à son tour remappe probablement le secteur avant d’écrire les données); si le même disque signale trop d'erreurs, le RAID le met hors ligne et informe l'administrateur (s'il est correctement configuré).
Jusqu'à présent, tout va bien, mais il y a des cas où des données défectueuses sortent d'un disque sans que le disque ne signale une erreur (voir la section suivante). La plupart des RAID peuvent détecter cette situation en utilisant les informations de parité, mais leur réaction est stupide: au lieu de signaler l'erreur et d'empêcher la transmission des données, ils recalculeront simplement la parité en fonction des données erronées et écriront la nouvelle parité dans la valeur respective disque, marquant ainsi les données défectueuses comme correctes pour toujours.
Est-ce un comportement raisonnable? Pour autant que je sache, la plupart des contrôleurs RAID5 matériels et même md RAID de Linux fonctionnent de cette façon.
Je ne connais pas la correction d'erreurs de btrfs, mais vous devriez éventuellement lire à nouveau attentivement les documents, notamment si vous utilisez le RAID de btrfs.
Pourriture de mors silencieuse
Malgré toutes les guerres de flammes et les discussions (pseudo-) scientifiques: la réalité est généralement différente de la théorie, et la pourriture silencieuse des bits se produit définitivement bien que la théorie puisse dire le contraire (la pourriture silencieuse des robots signifie généralement que les données sur le stockage matériel sont corrompues sans que le périphérique de stockage ne signale un erreur lorsque ces données sont lues, mais j'ajouterai des bits de retournement n'importe où dans le chemin de transmission à cette définition).
Ce n'est pas mon opinion personnelle: au moins Google, Amazon et le CERN ont publié des livres blancs détaillés couvrant exactement ce sujet. Les articles sont mis à la disposition du public et téléchargeables gratuitement. Ils ont fait des expériences systématiques avec plusieurs millions de disques durs et des centaines de milliers de serveurs / périphériques de stockage, soit parce qu'ils avaient des problèmes de corruption de données non détectées, soit parce qu'ils voulaient savoir quoi faire pour éviter cela avant qu'il ne se produise.
En résumé, les données de leurs batteries de serveurs avaient été corrompues avec un taux nettement supérieur aux statistiques MTBF ou à toute autre théorie. Par significativement plus élevé, je veux dire des ordres de grandeur.
La pourriture silencieuse des bits, c'est-à-dire une corruption de données non détectée à n'importe quel point du chemin de transmission, est un problème réel.
Durée de vie des données
Warren Young a raison lorsqu'il dit que les données d'échange ont une courte durée de vie. Mais je voudrais ajouter la considération suivante: Non seulement les données (au sens de documents) entrent en jeu, mais (peut-être encore plus probablement) des parties du système d'exploitation ou d'autres logiciels en cours d' exécution . Si j'ai un MP3 en swap, je pourrais vivre avec un bit de retournement. Si (en raison d'une situation extrême) des parties de mon logiciel de serveur de production httpd sont en swap, je ne peux en aucun cas vivre avec un bit de retournement qui conduit plus tard à exécuter du code corrompu s'il n'est pas détecté.
Épilogue
Pour moi, ZFS résout ces problèmes ou, plus précisément, il les éloigne des disques de la mémoire et réduit ainsi la probabilité de pourriture silencieuse des bits de quelques ordres de grandeur. De plus, s'il est correctement configuré (c'est-à-dire des miroirs au lieu de RAID), il fournit une correction d'erreurs propre et raisonnable qui fonctionne comme prévu et peut être facilement comprise après tout.
Cela dit, veuillez noter que vous n'obtiendrez jamais une sécurité absolue. Personnellement, je fais plus confiance à ma RAM ECC qu'à mes disques, et je suis convaincu que ZFS avec ses sommes de contrôle de bout en bout réduit la probabilité de problème par ordre de grandeur. Cependant, je ne recommanderais jamais d' utiliser ZFS sans RAM ECC.
Avertissement: je ne suis en aucun cas associé à un fournisseur ou développeur ZFS. Cela est vrai pour toutes les variantes (fourches) de ZFS. J'en suis juste devenu fan ces derniers jours ...
la source