Système de fichiers qui ne casse jamais (perte de données acceptable)

Il existe plusieurs sujets existants autour de cette question, mais ce que je recherche est légèrement différent. J'ai une carte SD sur un Linux embarqué et elle souffre d'une coupure de courant. Je pourrais peut-être modifier le matériel à un moment donné, fermer correctement et ainsi de suite, etc. Mais pour l'instant, je voudrais juste trouver un système de fichiers qui survit à la perte de puissance sans chichi. La perte de données est acceptable. Je préfère ne pas perdre plus que le fichier que j'écris actuellement, mais je préfère tout perdre plutôt que de faire face à un 'incapable de monter', 'attendre ce fsck de 10 minutes' ou 'incapable de créer un nouveau fichier à cause de cet inode quelque chose quelque chose d'erreur '. Le programme DOIT continuer!

Je fais beaucoup d'efforts pour y parvenir. J'utilise des composants de qualité industrielle, j'ai des chiens de garde matériels, des chiens de garde logiciels, internes, externes, initialise le redémarrage des programmes, des démons vérifiant constamment la mémoire, les descripteurs de fichiers et ainsi de suite, j'ai des chiens de garde qui regardent mes chiens de garde, qui à leur tour sont surveillés par d'autres chiens de garde ... Mais je n'arrive pas à garantir que la carte SD est capable de monter et de fonctionner?

Mon meilleur pari en ce moment, est d'utiliser JFS sur la carte SD, d'inclure fsck et fsck.jfs dans mon installation. (Ajout de 600 Ko + manger mon RAM et mon flash. Ce qui est mauvais.) Et exécutez fsck à chaque démarrage (peut-être en ajoutant beaucoup de temps de démarrage. Ce qui est quelque peu mauvais.). Cela semble un peu triste cependant.

Quelqu'un connaît-il un meilleur moyen ou un meilleur système de fichiers?

MISE À JOUR: e2fsprogs-libs (dépendance à jfsutils) semble être terriblement difficile à compiler dans ma distribution. Je vais regarder dans ZFS (il n'est pas natif de ma distribution cependant. Et il semble faire beaucoup de choses dont je n'ai pas besoin.)

UPDATE2: Quelques informations supplémentaires sur mon système et mes tests: Le stockage de la carte SD est un stockage secondaire en option. Les cartes SD sont des microSD de qualité industrielle 2 Go-8 Go. La carte SD est montée via mon rc avec une commande mount -t. Options "noatime" mais pas "sync". Ma distribution est un uClinux personnalisé au format Analog Device, avec un noyau 3.10 et une boîte occupée 1.21. Mon stockage principal est un flash spi avec jffs2. Je n'ai jamais eu de problème avec ça. Je ne sais même pas s'il y a un fsck.jffs2 disponible. Nand flash d'autre part ... mais c'est une autre histoire. Le but de la carte SD est de stocker les données de mesure. Le programme «moniteur» ajoutera les résultats à un fichier et aura des emplacements de synchronisation stratégiques. Lorsque le fichier dépasse une taille donnée, un nouveau sera créé. Lorsqu'un nombre donné de fichiers a été atteint, le plus ancien est supprimé. Si le fichier de mesure actuel est perdu en raison d'une panne de courant, ce n'est pas une catastrophe. Les fichiers sont généralement de 50 à 100 Ko et 1 résultat est généralement de 1 Ko. Ce n'est que la phase de développement initiale. Rien n'est réparé. C'est la première fois que je traite des systèmes de fichiers non flash dans des systèmes embarqués. (J'ai eu ext4 sur mes serveurs x86.)

J'ai commencé avec vfat. Le système de fichiers par défaut. (J'ai pensé que les usines pourraient avoir une raison de le choisir. Et si les choses fonctionnent, je m'en fiche vraiment.) Je n'ai jamais vu de problèmes de perte d'alimentation dans mes périphériques vfat intégrés. J'ai cependant rencontré des problèmes avec FAT dans WinCE. Cependant, lorsque mon programme «moniteur» a atteint 100 à 200 fichiers, il a refusé d'en créer davantage. Il semble que FAT ait un problème de limite de fichier spécial à la racine et un problème légèrement plus important dans les sous-répertoires. J'ai besoin de pouvoir créer 500 à 1000 fichiers dans 1 dir. Donc vfat ne fera pas l'affaire.

Ensuite, je suis passé à ext2. Je n'ai cependant pas inséré de fsck au démarrage. (Je ne savais pas que je devais le faire.) En un jour, mon programme «moniteur» n'a pas pu créer plus de fichiers en raison d'une erreur «inode quelque chose de quelque chose». Catastrophe!

Ma solution actuelle est ext2 avec un "e2fsck -y" au démarrage. Jusqu'à présent, cela semble prometteur. Mais l'e2fsck et tout le concept de «fsck au démarrage» me harcèlent. Le e2fsck par lui-même dépense plus de 350 Ko de mon flash principal et de son RAM. (Quand il ne fonctionne pas.) Ce qui signifie que c'est mon plus gros programme. C'est plus grand que busybox. Il rivalise presque avec mon noyau.

J'ai envisagé ext3. Il a journalisé des métadonnées, ce qui ne ferait pas de mal. Je doute cependant que cela puisse aider. Avec mes petits fichiers et mes synchronisations contrôlées, je devrais être couvert je pense? Il a une séquence d'écriture ordonnée. Cela signifie que les données sont également quelque peu journalisées. Cela peut cependant conduire à des retards non déterministes. Ce qui est mauvais dans ma situation. (Ce n'est probablement pas un problème.) Il dispose également d'une fonction de synchronisation planifiée. Par exemple. commit toutes les 5 sec. Ce qui interfère avec mes propres synchronisations, je pense. Trop d'écritures sont mauvaises pour les cartes SD. Même industriels. Je ne trouve aucune documentation sur la façon de désactiver cela. Et ext3 nécessite toujours l'exécution de fsck à chaque démarrage! Mais ext3 est toujours une possibilité.

Ext4. Résoudra un grand nombre des problèmes de performances d'ext3. Mais je n'ai pas vraiment besoin de performances. Et ma distribution ne semble pas avoir un mkfs.ext4 et un fsck.ext4 intégrés. Ce n'est peut-être pas un problème. Cela pourrait cependant. Par exemple. les e2progs-libs (dépendance à jfsutils) semblent avoir beaucoup de problèmes de compilation.

JFS, XFS, BRFSS. Tous pris en charge par mon noyau. Actuellement non inclus dans ma boîte à outils de l'espace utilisateur. Tout semble être des systèmes assez grands et complexes. Et ils semblent tous nécessiter un équivalent «fsck» au démarrage?

J'ai également envisagé de lancer mon propre système de fichiers: écrivez toujours 2 copies de la table de fichiers. Lors de la traversée, il sélectionne celui avec le CRC correct et le numéro de séquence le plus récent. Créez une séquence d'écriture en deux étapes. Allouer temporaire, corriger lors de la validation. Aucun fsck nécessaire. J'ai bien peur que ce soit un peu naïf.

MISE À JOUR3: BTW, la nature des systèmes embarqués (celui-ci au moins) est qu'ils sont autonomes, sans surveillance, hors de portée, et ils doivent fonctionner pendant des années. Des programmes comme fsck qui peuvent nécessiter une interaction humaine me font peur.

Il y a un peu d'incohérence ou du moins d'ambiguïté dans votre histoire ici:

Je préfère tout de même tout perdre plutôt que de faire face à un 'incapable de monter', 'attendez ce fsck de 10 minutes'

Implique - bien que vous ne le disiez pas réellement - que c'est un problème que vous rencontrez réellement. Mais alors:

e2fsprogs-libs (dépendance à jfsutils) semble être terriblement difficile à compiler dans ma distribution.

Cela signifie que vous n'avez aucun fsck du tout , car e2fsprogs-libsc'est une dépendance pour e2fsprogslaquelle fournit e2fsck. Alors peut-être que vous êtes encore dans une phase de planification ici et que vous n'avez même pas testé le système avec, par exemple ext4, mais que vous êtes plutôt parvenu à la conclusion que vous devriez commencer avec JFS? Y a-t-il une raison particulière à cela?

J'ai remarqué sur l'échange Raspberry Pi (le stockage principal du Pi est également une carte SD) qu'un nombre important d'utilisateurs semblent très frustrés par des problèmes de ce type, même si la majorité (y compris moi-même) ne l'ont jamais eue à tout. Au début, je supposais que ces personnes ignoraient que le système devait être arrêté proprement, mais ce n'est pas un point difficile à comprendre une fois expliqué, et il y a des gens qui le signalent même si le système a été correctement arrêté .

Vous avez déjà dit que vous en avez besoin pour pouvoir tolérer les coupures de courant (ce qui est assez juste), mais je le mentionne car cela implique qu'il y a des pis, ou des cartes SD, ou une combinaison des deux, qui sont juste sujettes à corrompre le système de fichiers en raison d'un événement (surtension?) qui se produit régulièrement soit lorsque la fiche est retirée, soit lorsqu'elle est remise en place. Je n'ai pas non plus vu - et il y a eu beaucoup de temps pour que beaucoup de gens essaient - N'IMPORTE QUELS rapports de quelqu'un disant qu'ils sont passés à btrfs ou jfs ou quoi que ce soit et maintenant le problème est résolu.

L'autre chose mystérieuse à ce sujet est que même si les gens tirent sur le cordon, cela ne devrait pas entraîner régulièrement un système de fichiers inutilisable. Certes, je l'ai fait un tas de fois avec le pi, et des scores sinon des centaines de fois avec une boîte Linux régulière (l'alimentation a été coupée, le système est devenu insensible, je suis épuisé et en colère, etc.) et même si j'ai vu une perte de données mineure, je n'ai jamais vu un système de fichiers corrompu au point d'être inutilisable après un rapide fsck.

Encore une fois, en supposant que tous ces rapports sont vrais (je ne vois pas pourquoi un grand nombre de personnes mentiraient à ce sujet), il se passe bien plus que simplement ne pas démonter proprement, mais cela semble n'affecter qu'un petit pourcentage d'utilisateurs, ce qui implique à nouveau une sorte de défaut matériel commun.

Sur la pi j'écris -ypour /forcefsckdans un script de démarrage, de sorte que le prochain démarrage est exécuté automatiquement et tous les problèmes sont résolus, que cela semble être nécessaire ou non. Sur un cœur unique de 700 MHz, cela prend environ 10 secondes pour un système de fichiers de 12 Go contenant environ 4 Go de données. Ainsi , « 10 minutes » sonne comme un temps incroyablement long, d' autant plus que vous avez déjà dit « C'est le petit système de fichiers pour écrire! ».

Vous pouvez également envisager d'appeler syncà intervalles réguliers.

Enfin, vous devez mettre à jour la question avec des détails plus factuels et spécifiques des problèmes que vous avez réellement rencontrés, et moins d'hyperbole. Sinon, cela ressemble trop à un problème XY prématuré , qui sera probablement rapidement ignoré par des personnes ayant beaucoup d'expérience et des conseils potentiels pour vous.

Le programme DOIT continuer!

Eh bien, c'est une exigence courante et les systèmes Linux sont le meilleur choix lorsqu'il s'agit de choisir un système stable.

Vos efforts semblent également ne pas aller dans la bonne direction. Mais que pouvez-vous faire pour obtenir un système stable?

Au premier niveau, vous pouvez améliorer votre système de fichiers:

• Utiliser yournal_data_orderedsur un ext3/ext4système de fichiers, lors de la création ou de la modification avec tune2fs.
• À JFSutiliser --replay_journal_onlylors de la vérification.
• Activez la réparation automatique en définissant FSCKFIX=yesdans les scripts d'initialisation .

Si cela ne suffit pas, vous pouvez démarrer votre système sans monter le disque buggy. Au lieu de cela, créez un nouveau ramdiskpendant que vous vérifiez et réparez manuellement votre disque de buggy. Cela peut également être automatisé par des scripts.

Au niveau suivant, vous devrez quitter votre système intégré et lire quelques rubriques sur la haute disponibilité