Devrais-je utiliser fsck ext3 sur un système embarqué?

Question

Nous avons un certain nombre de systèmes intégrés nécessitant un accès r / w au système de fichiers qui réside sur un stockage flash avec une émulation de périphérique en mode bloc. Notre plate-forme la plus ancienne fonctionne en compact flash. Ces systèmes sont utilisés depuis plus de 3 ans sans qu'une seule commande fsck ne soit exécutée au démarrage. Nous n'avons jusqu'à présent aucune défaillance attribuée au système de fichiers ou au système de fichiers.

Sur notre dernière plate-forme, nous avons utilisé une clé USB pour la production initiale et nous effectuons actuellement la migration vers un disque sur module pour le stockage en lecture / écriture. Il y a quelque temps, nous avions des problèmes avec le système de fichiers de nombreux périphériques fonctionnant sur un stockage USB. J'ai donc activé e2fsck afin de voir si cela aiderait. Comme il s’est avéré que nous avions reçu une cargaison de mauvais mémoires flash, le problème a disparu une fois remplacées. Depuis, j’ai désactivé e2fsck, car nous n’avions aucune raison de croire que le système était plus fiable et, d’habitude, nous nous en sommes bien passés.

Maintenant que nous avons commencé à installer des unités Disk-on-Module, j'ai de nouveau constaté des erreurs dans le système de fichiers. Tout à coup, le système est incapable de lire / écrire certains fichiers et si j'essaie d'accéder au fichier à partir de la console d'urgence, je ne reçois que & "; Erreur d'entrée / sortie &"; J'ai réactivé e2fsck et tous les fichiers ont été corrigés.

O'Reilly " Construire des systèmes Linux embarqués " recommande d’exécuter e2fsck sur des systèmes de fichiers ext2 mais ne le mentionne pas en relation avec ext3, je suis donc un peu confus de savoir si je devrais l’activer ou non.

Que pensez-vous de l’exécution de fsck sur un système embarqué? Nous envisageons de placer des fichiers binaires sur une partition et uniquement les fichiers qui doivent être modifiés sur une partition sur le même périphérique flash, de sorte que fsck ne puisse jamais supprimer accidentellement des fichiers binaires système importants. (bon / mauvais)?

Answer 1

Je pense que la réponse à votre question concerne davantage les types d'exigences de cohérence que votre application a par rapport à ses données. En d’autres termes, que faut-il garantir en cas de coupure de courant sans arrêt formel du système? En règle générale, aucun des systèmes de fichiers de type système d'exploitation de bureau ne résout ce problème sans une fermeture / synchronisation spécifique des applications et le vidage des caches de disque, etc. aux points de transaction clés de l'application pour garantir la conservation de ce que vous devez gérer. fait commis aux médias.

L'exécution de fsck corrige le système de fichiers, mais sans les soins ci-dessus, rien ne garantit que les modifications que vous avez apportées seront réellement conservées. C'est-à-dire que ce que vous perdrez à la suite d'une panne de courant n'est pas exactement déterministe.

Je conviens que le fait de placer vos fichiers binaires ou d'autres données importantes en lecture seule sur une partition distincte en lecture seule vous aide à éviter qu'ils ne soient renvoyés par erreur en raison d'une correction fsck des structures de système de fichiers. Au minimum, les placer dans un sous-répertoire différent de la racine où se trouvent les données R / W aidera. Mais dans les deux cas, si vous prenez en charge les mises à jour logicielles, vous devez toujours disposer d’un système permettant d’écrire le & Quot; lecture-seule & Quot; zones de toute façon.

Dans notre application, nous maintenons en fait une paire de répertoires pour des éléments tels que les fichiers binaires et le système est configuré pour démarrer à partir de l’un ou l’autre des deux domaines. Lors des mises à jour logicielles, nous mettons à jour le premier répertoire, synchronisons tout sur le support et vérifions les sommes de contrôle MD5 sur le disque avant de passer à la mise à jour de la deuxième copie. Au démarrage, ils ne sont utilisés que si la somme de contrôle MD5 est bonne. Cela garantit que vous démarrez toujours une image cohérente.

Answer 2

Dave,

Je recommande toujours d'exécuter fsck après un certain nombre de redémarrages, mais pas à chaque fois.

La raison en est que l’ext3 est journalisé. Donc, sauf si vous activez l'écriture différée (sans journal), la plupart du temps, votre table de métadonnées / système de fichiers doit être synchronisée avec vos données (fichiers).

Mais comme Jeff l'a mentionné, cela ne garantit pas la couche au-dessus du système de fichiers. Cela signifie que vous obtenez toujours & "; Corrompu &"; fichiers, car certains enregistrements n'ont probablement pas été écrits dans le système de fichiers.

Je ne suis pas sûr du périphérique intégré sur lequel vous travaillez, mais à quelle fréquence redémarre-t-il? S'il s'agit d'un redémarrage contrôlé, vous pouvez toujours faire & "Sync; sync; sync &"; avant de redémarrer.

J'utilise les FC moi-même depuis des années et, très rarement, j'ai eu des erreurs de système de fichiers. fsck aide dans ce cas.

Et à propos de la séparation de votre partition, je doute de son avantage. Une métadonnée est associée à chaque donnée / fichier du système de fichiers. La plupart du temps, si vous ne modifiez pas les fichiers, par exemple. fichiers binaires / système, alors ces métadonnées ne devraient pas changer. À moins que votre matériel ne soit défectueux, par exemple une conversation croisée, écrivez & Amp; en lecture seule, ces fichiers en lecture seule doivent être sûrs.

La plupart des problèmes surviennent lorsque vous avez un élément en écriture et quel que soit l'endroit où vous le placez, cela peut poser problème si l'application ne le gère pas correctement.

L’espoir que cela aide.