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 :
vrai, mais cela ne protégera pas contre les retournements de bits en dehors du disque lui-même
"Ça" 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 les données de manière indétectable 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 rare et aléatoire comme les rayons cosmiques provoquerait des erreurs indétectables à un taux extrêmement faible.
Sachez également que si vous avez une source qui provoque une erreur non détectée à un taux proche d'un par 125 Mio transférés, les performances seront terribles en raison du nombre élevé de détectés erreurs nécessitant un nouveau transfert. La surveillance et la journalisation vous alerteront probablement du problème à temps 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 d'une certaine sorte. L'une des caractéristiques des disques durs "d'entreprise" est que les secteurs plus grands sont protégés par des fonctionnalités supplémentaires d'intégrité des données, ce qui réduit considérablement le risque d'erreur non détectée.
Sans de telles mesures, le pool de secteurs de secours de chaque disque dur n'aurait aucun sens :le disque 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 :
si SATA est si digne de confiance, pourquoi existe-t-il des systèmes de fichiers à somme de contrôle tels que ZFS, btrfs, ReFS ?
De manière générale, nous ne demandons pas d'échange pour stocker des données à long terme. La limite du stockage d'échange est la disponibilité du système, et la plupart des données échangées ne durent pas aussi longtemps, car la plupart des données qui passent 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é sont généralement devenus plus courts au fil des ans, avec la fréquence accrue du noyau et de libc mises à jour, virtualisation, architectures cloud, etc.
De plus, la plupart des données d'échange sont intrinsèquement désutilisées dans un système bien géré, étant un système qui ne manque pas de RAM principale. Dans un tel système, les seules choses qui se retrouvent dans le swap sont les pages que le programme n'utilise pas souvent, voire jamais. Ceci est plus courant que vous ne le pensez. La plupart des bibliothèques dynamiques que vos programmes lient contiennent des routines que votre programme n'utilise pas, mais elles ont dû être chargées dans la RAM par l'éditeur de liens dynamique. Lorsque le système d'exploitation voit que vous n'utilisez pas tout le texte du programme dans la bibliothèque, il l'échange, faisant de la place pour le code et les données que vos programmes sont utilisant. Si de telles pages de mémoire échangées sont corrompues, qui le saura jamais ?
Comparez cela avec les goûts de 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 le swap Linux.
ZFS et autres diffèrent de l'échange d'une autre manière clé ici :nous n'échangeons pas les systèmes de fichiers RAID ensemble. Lorsque plusieurs périphériques d'échange 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 chaînés de macOS, le swapon de Linux , 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 rechercher d'autres périphériques d'échange interdépendants pour les données qui doivent aller sur le périphérique de remplacement . En termes ZFS, nous ne réargentons pas les périphériques d'échange à partir de copies redondantes sur d'autres périphériques de stockage.
Tout cela signifie que vous devez utiliser un périphérique d'échange fiable. Une fois, j'ai utilisé un boîtier de disque dur USB externe à 20 $ pour sauver un pool ZFS en difficulté, seulement pour découvrir que le boîtier n'était pas lui-même fiable, introduisant ses propres erreurs dans le processus. La forte somme de contrôle de ZFS m'a sauvé ici. Vous ne pouvez pas vous en sortir avec un traitement aussi cavalier des supports de stockage avec un fichier d'échange. Si le périphérique d'échange est en train de mourir et s'approche donc 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 vous, en 2019, avez de nouvelles idées à ajouter à ce problème. Et si ce n'est pas le cas, alors peut-être allez-vous simplement utiliser la technologie conçue par trois décennies de diplômés en informatique qui connaissent tous le problème des généraux byzantins.
C'est un terrain bien rodé. Vous ne pouvez probablement pas proposer une idée, une objection ou une solution qui n'a pas déjà été discutée à mort dans les revues informatiques.
SATA n'est certainement pas totalement fiable, mais à moins que vous ne rejoigniez l'université ou l'une des équipes de développement du noyau, vous ne serez pas en mesure d'ajouter matériellement à l'état de l'art ici. Ces problèmes sont déjà bien maîtrisés, comme vous l'avez déjà noté :ZFS, btrfs, ReFS... En tant qu'utilisateur de 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 aussi sur les généraux byzantins.
Il n'est actuellement pas pratique de placer votre fichier d'échange sur ZFS ou 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.
Swap a ??? <--- c'est ma question
L'échange n'est toujours pas protégé sous Linux (mais voir UPD).
Eh bien, bien sûr, il y a ZFS sur Linux qui est capable d'être un stockage d'échange, mais il y a toujours un blocage dans certaines circonstances - révoquant ainsi 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é que ses performances sont médiocres. Il y a une indication peu claire que Linux 5 pourrait enfin l'avoir (?)…
Les correctifs pour protéger l'échange conventionnel lui-même avec des sommes de contrôle ne se sont pas généralisés.
Donc, dans l'ensemble :non. Linux a encore une lacune là-bas.
MISE À JOUR. :Comme le souligne @sourcejedi, il existe un outil tel que dm-integrity. Le noyau Linux depuis la version 4.12 a obtenu la cible du mappeur de périphérique 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 intégré dans les principales distributions et la plupart d'entre eux n'ont aucun support dans le sous-système udev, mais cela devrait éventuellement changer. Lorsqu'il est associé à un fournisseur de redondance, par exemple placé sur un haut de MD alias Linux Software RAID, il devrait être possible non seulement de détecter la pourriture des bits, mais également de réacheminer la demande d'E/S vers des données saines, car dm-integrity indiquerait qu'il y a un problème et MD devrait s'en occuper.
dm-intégrité
Voir :Documentation/device-mapper/dm-integrity.txt
dm-integrity serait normalement utilisé en mode journalisation. En cas d'échange, vous pouvez vous arranger pour vous passer de la journalisation. Cela pourrait réduire considérablement la surcharge de performances. Je ne sais pas si vous auriez besoin de reformater la partition swap-over-integrity à chaque démarrage, pour éviter de détecter des erreurs après un arrêt incorrect.
Dans l'annonce initiale du 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 d'un échange, 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 l'échange efficacement en utilisant des étendues, et non des pages / secteurs individuels).
DIF/DIX ?
La prise en charge de DIX a été ajoutée par Oracle dans Linux 2.6.27 (2008).
L'utilisation de DIX offre-t-elle une intégrité de bout en bout ?
Vous pourriez consulter votre fournisseur. Je ne sais pas comment vous pouvez savoir s'ils mentent à ce sujet.
DIX est nécessaire pour protéger les données en transit entre le système d'exploitation (système d'exploitation) et le HBA .
DIF à lui seul augmente la protection des données en transit entre le HBA et le périphérique de stockage . (Voir aussi :présentation avec quelques chiffres sur la différence des taux d'erreur).
Précisément parce que la somme de contrôle dans le champ de garde est normalisée, il est techniquement possible d'implémenter des commandes DIX sans en fournir aucune protection des données au repos. Demandez simplement 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 assez claire par le projet DIX original.
- DIF/DIX sont orthogonaux aux sommes de contrôle des blocs logiques
- Nous vous aimons toujours, btrfs !
- Les erreurs de somme de contrôle des blocs logiques sont utilisées pour détecter les données corrompues
- La détection se produit au moment de la lecture
- ... qui pourrait être des mois plus tard, le tampon d'origine est perdu
- Toute copie redondante peut également être mauvaise si le tampon d'origine a été brouillé
- DIF/DIX visent à prévenir de manière proactive la corruption
- Éviter en premier lieu que les données erronées ne soient stockées sur le disque
- ... et découvrir les problèmes avant que le tampon d'origine ne soit effacé de la mémoire
-- lpc08-data-integrity.pdf de oss.oracle.com
L'un de leurs premiers messages sur DIX mentionne la possibilité d'utiliser DIX entre le système d'exploitation et le HBA même lorsque le lecteur ne prend pas en charge DIF.
Le mensonge complet est relativement improbable dans les 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 exigerait que vous reformatiez d'abord le lecteur, voir par ex. le sg_format commande.
Ce qui est plus probable, c'est une implémentation 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 afin d'é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 peut générer ses propres sommes de contrôle et les stocker dans l'espace des balises d'application. Cependant, cela n'est pas pris en charge 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 sais pas si cela fait référence au périphérique de stockage lui-même, au HBA ou aux deux).
Quels types d'appareils DIX fonctionnent avec Linux ?
La séparation des tampons de données et de métadonnées d'intégrité ainsi que le choix des sommes de contrôle est appelée Data IntegrityExtensions [DIX]. Comme ces extensions sortent du périmètre des instances protocolaires (T10, T13), Oracle et ses partenaires tentent de les normaliser au sein de la Storage Networking Industry Association.
-- v4.20/Documentation/block/data-integrity.txt
Wikipedia me dit que DIF est standardisé dans NVMe 1.2.1. Pour les HBA SCSI, il semble un peu difficile de cerner cela si nous n'avons pas de norme à pointer. Pour le moment, il serait peut-être plus précis de parler du support "Linux DIX" :-). Il existe des appareils disponibles :
SCSI T10 DIF/DIX [sic] est entièrement pris en charge dans Red Hat Enterprise Linux 7.4, à condition que le fournisseur de matériel l'ait qualifié et fournisse une prise en charge complète pour la configuration particulière du HBA et de la baie de stockage. DIF/DIX n'est pas pris en charge sur d'autres configurations, il n'est pas pris en charge pour une utilisation sur le périphérique de démarrage et il n'est pas pris en charge sur les invités virtualisés.
À l'heure actuelle, les fournisseurs suivants sont connus pour fournir ce support...
-- Notes de version de RHEL 7.5, chapitre 16. Stockage
Tout le matériel mentionné dans les notes de publication 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 devient disponible plus largement sur NVMe.