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