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.