Quel système de fichiers offre la meilleure protection pour sécuriser les données contre la corruption due à une panne de courant?

Je courais un petit uClibcet busyboxsystème embarqué basé sur un dispositif x86. J'utilise un initramfs mais je monte également un ext3répertoire personnalisé sur un périphérique compact flash en mode IDE que j'utilise pour stocker des données d'enregistrement de mesure persistantes créées par une application c ++ écrite personnalisée. J'ai choisi le ext3système de fichiers car il est recommandé pour la sécurité contre les pertes de puissance lors de l'utilisation de lecteurs CF en mode IDE dans quelques livres que j'ai lus ( Building Embedded Linux Systems par Karim Yaghmour et Embedded Linux Primer par Christopher Hallinan). Ceci est particulièrement important et les données sont essentielles.

Cependant, en raison de certains des commentaires de ma question précédente Confusion avec la façon de restaurer des fichiers ext3 corrompus en cas de panne de courant pendant l'écriture d'un fichier, il semblerait qu'en fait, ce système de fichiers n'offre pas la garantie de sécurité contre la corruption de données due à l'alimentation perte. Je voudrais donc savoir si

1. Est-ce ext3réellement le meilleur choix pour cette configuration?
2. La perte de puissance pendant une opération d'écriture de disque ne corrompe-t-elle que périodiquement la partie des données que j'ajoute au fichier ou peut-elle corrompre l' intégralité du fichier?
3. Les données qui ne sont pas écrites au moment de la coupure de courant sont-elles totalement sûres? En particulier, y a-t-il un risque que mon initramfs.cpiofichier soit également corrompu?
4. Existe-t-il une méthode que je peux utiliser dans mon code d'application pour protéger les données (c'est-à-dire créer une partition supplémentaire et écrire mes données pour refléter les images afin qu'il y ait toujours 2 copies) - la vitesse n'est pas un vrai problème pour mon application, des opérations de copie si coûteuses sont acceptables.

J'ai vu et lu les réponses à cette question connexe: les systèmes de fichiers de journalisation garantissent-ils contre la corruption après une panne de courant? , mais cela ne couvre pas tout à fait certaines des choses qui me déroutent.

Je me rends compte que je pose beaucoup de questions, mais il semble qu'en dépit de la lecture de beaucoup de documents, j'ai eu un échec fondamental à comprendre les risques pour mes données en cas de panne de courant.

Comme pour tout ce qui concerne la sécurité, il n'y a aucune garantie, mais vous devez également équilibrer le risque (et le coût) par rapport à la probabilité. Par expérience (et j'exécute des dizaines de * nix boxen depuis les âges sombres), je n'ai jamais vraiment eu de corruption de système de fichiers causée par l'alimentation.

Certaines de ces machines fonctionnaient même sur des systèmes de fichiers non journalisés (ufs et ext2 en général). Certains d'entre eux étaient intégrés, et quelques-uns étaient des téléphones portables comme le Nokia N900 - donc une bonne alimentation n'était pas du tout garantie.

Ce n'est pas que la corruption du système de fichiers ne peut pas se produire, c'est juste que la probabilité qu'elle se produise est suffisamment faible pour que cela ne vous inquiète pas. Pourtant, aucune raison de ne pas couvrir vos paris.

En réponse à vos questions littérales:

1. Au moins le premier livre ext4auquel vous avez fait référence a été écrit auparavant - lorsque l'auteur suggère d'utiliser ext3, ils disent vraiment «n'utilisez pas de systèmes de fichiers instables ou non journalisés comme ext2»). Essayez ext4, il est assez mature et propose des options décentes pour les disques qui ne tournent pas, ce qui peut prolonger la durée de vie de votre périphérique flash.
2. Il y a de fortes chances que vous perdiez le dernier bloc ou les deux derniers, pas le fichier entier. Avec un système de fichiers journalisé, ce sera à peu près la seule perte. Il existe des scénarios d'échec où je pourrais voir des données aléatoires dispersées sur le fichier, mais elles semblent à peu près aussi probables qu'une micrométéorite se brisant directement à travers votre appareil intégré.
3. Voir 2. Rien n'est sûr à 100,00%.

4. Si vous avez un deuxième canal IDE, collez-y une deuxième carte CF et récupérez périodiquement une sauvegarde du système de fichiers. Il y a quelques façons de le faire: rsync, cp dump, dd, même en utilisant le md(4)dispositif (RAID logiciel) (vous ajoutez le deuxième disque de temps en temps, laissez - le synchroniser, puis retirez - si les deux appareils sont sous tension tout le temps, ils courent le même risque de corruption de système de fichiers). Si vous utilisez LVM, vous pouvez même saisir des instantanés. Pour un appareil intégré de collecte de données, je n'utiliserais qu'une solution ad hoc qui monte le deuxième système de fichiers, copie sur le journal de données, le démonte immédiatement. Si vous avez peur que l'appareil ait une bonne image de démarrage, collez une deuxième copie du gestionnaire de démarrage et toutes les images de démarrage nécessaires sur le deuxième appareil et configurez l'ordinateur pour démarrer à partir de l'une ou l'autre des cartes CF.

   Je ne ferais pas confiance à une deuxième copie sur le même appareil car les périphériques de stockage échouent plus souvent que les systèmes de fichiers stables. Beaucoup plus souvent, d'après mon expérience jusqu'à présent (au travail, il y avait une demi-blague amère sur les chances étrangement élevées de défaillances de disque vendredi après-midi. C'était presque un événement hebdomadaire pendant un certain temps). Que le disque tourne ou non, il peut échouer. Conservez donc vos œufs dans deux paniers si vous le pouvez, et vous protégerez mieux vos données.

   Si les données sont particulièrement sensibles, je rendrais régulièrement visite à l'appareil, j'échangerais la sauvegarde CF pour une nouvelle et redémarrerais, en lui laissant fscktous ses systèmes de fichiers pour faire bonne mesure.

Il me semble que ce qu'une implémentation de système de fichiers peut réaliser en cas de coupure de courant soudaine est limité - après tout, il s'agit en fait d'une interface avec le matériel, alors que se passe-t-il entre le moment où il envoie des données / instructions au matériel et le moment où il obtient une réponse est hors de son contrôle. S'il y avait un système de fichiers qui pourrait contourner ce problème, vous en auriez entendu parler.

De ce fait, une stratégie de protection des données critiques bénéficiera le plus des décisions prises au niveau matériel , par exemple en utilisant une alimentation sans coupure. Ce n'est probablement pas si faisable dans votre situation.

Vous avez dit que les performances n'étaient pas vraiment un gros problème, alors utilisez-les judicieusement fsync().

La perte de puissance pendant une opération d'écriture de disque ne corrompe-t-elle que périodiquement la partie des données que j'ajoute au fichier ou peut-elle corrompre l'intégralité du fichier?

J'utilise des systèmes de fichiers extN personnellement et sur des serveurs Internet à faible trafic depuis des années, et comme Alexios, je n'ai pas vu beaucoup de corruption due à une panne de courant (bien que pour être juste, les serveurs ont UPS et je ne me souviens pas l'un d'eux descend en fait de cette façon). Un problème beaucoup plus grave est la corruption due à une défaillance matérielle, qui différents systèmes de fichiers peuvent (encore) être de plus en moins capables de traiter le problème, mais (encore une fois) cela est fondamentalement indépendant de leur volonté et ils ne peuvent pas l'empêcher.

J'ai parfois vu des fichiers perdus ou tronqués à zéro. Je présume qu'il y a de fortes chances que ceux-ci soient récupérables d'une manière ou d'une autre; ce n'était pas nécessaire pour moi car ils étaient sauvegardés. La plupart du temps, s'il y a quelque chose qui ne va pas, cela fscksemble régler le problème.

Les données qui ne sont pas écrites au moment de la coupure de courant sont-elles totalement sûres? En particulier, y a-t-il un risque que mon fichier initramfs.cpio soit également corrompu?

Je pense que le risque est vraiment très faible à cause d'une simple panne de courant, sauf que le type de stockage flash de corruption peut être sujet à cause de la surtension qui peut accompagner les pannes de courant - avec lesquelles je n'ai aucune expérience, mais j'espère que vous y avez pensé et fait des recherches sur cela.

Existe-t-il une méthode que je peux utiliser dans mon code d'application pour protéger les données?

Il vaut la peine de répéter le point sur fsync () . Les objets C ++ / iostream n'ont pas de méthode pour cela (:: flush et :: sync ne sont pas fsync), mais tout ce dont vous avez besoin est un descripteur de fichier.

ZFS est définitivement un système de fichiers protégé contre la corruption par sa conception et peut-être le seul. Cependant, je ne suis pas sûr de la disponibilité des implémentations ZFS (basées sur des fusibles ou natives) pour les plates-formes basées sur uClinux.

Il existe au moins un système de fichiers commercial qui fait un travail formidable en s'assurant que le système de fichiers ne peut presque pas être corrompu en raison de pannes de courant et que les seules données que vous risquez de perdre sont des données qui ont été ajoutées lors de la coupure de courant.

L'inconvénient est qu'il est très cher, ils offrent un excellent soutien. En raison des dépenses, ce n'est vraiment qu'une option pour les produits à enjeux élevés et / ou à volume élevé. Tout comme les équipements embarqués critiques dans la production de pétrole et de gaz, par exemple, qui doivent garantir l'intégrité du système dans des conditions de fonctionnement "incertaines" (par exemple, coupures de courant fréquentes, etc.).

Découvrez DataLight (société) et / ou le produit " Reliance NITRO ". (Reliance est leur solution héritée et sûre mais pas très efficace, remplacée par Reliance NITRO ). Même si vous n'avez pas d'argent pour utiliser ce système, ils ont de très bons articles expliquant comment leur système fonctionne, pourquoi il est plus fiable que par exemple ext3 et ext4.

Je m'excuse si cela se lit comme une annonce, je voulais simplement souligner les options.