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

Question

Nous avons un certain nombre de systèmes embarqués nécessitant un accès r/w au système de fichiers qui réside sur le stockage flash avec l'émulation de périphérique de bloc. Notre plate-forme la plus ancienne fonctionne sur flash compact et ces systèmes sont utilisés depuis plus de 3 ans sans qu'un seul fsck ne soit exécuté pendant le démarrage et jusqu'à présent, nous n'avons pas de défaillances attribuées au système de fichiers ou CF. Sur notre nouvelle plate-forme, nous avons utilisé le flash USB pour la production initiale et migrons maintenant vers le Disk-on-Module pour le stockage r/w. Il y a quelque temps, nous avions des problèmes avec le système de fichiers sur beaucoup de périphériques fonctionnant sur le stockage USB. J'ai donc activé e2fsck pour voir si cela pouvait aider. Comme il s'est avéré que nous avions reçu une cargaison de mauvais souvenirs flash, une fois ceux-ci remplacés, le problème a disparu. J'ai depuis désactivé e2fsck puisque nous n'avions aucune indication que cela rendait le système plus fiable et historiquement nous nous en sommes bien sortis.

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

O'Reilly « Building Linux Embarqué Systems » recommande d'exécuter e2fsck sur ext2, mais les systèmes de fichiers ne mentionne pas par rapport à ext3, donc je suis un peu confus de savoir si je l'activer ou non.

Que pensez-vous de lancer fsck sur un système embarqué? Nous envisageons de mettre des binaires sur la partition ar/o et seulement les fichiers qui doivent être modifiés sur la partition ar/w sur le même périphérique flash afin que fsck ne puisse jamais supprimer accidentellement des binaires système importants, quelqu'un a-t-il de l'expérience avec ce type de configuration (bon mauvais)?

Answer 1

Je pense que la réponse à votre question plus se rapporte aux types d'exigences de cohérence que votre application a par rapport à ses données. C'est-à-dire, qu'est-ce qui doit être garanti si le pouvoir est perdu sans une fermeture officielle du système? En général, aucun système de fichiers de type système d'exploitation de bureau ne gère bien cela sans fermeture/synchronisation spécifique des fichiers et vidage des caches de disque, etc. aux points de transaction clés de l'application pour assurer que ce que vous devez maintenir est en fait commis aux médias.

L'exécution de fsck corrige le système de fichiers, mais sans les précautions ci-dessus, il n'y a aucune garantie quant aux modifications que vous allez effectuer. c'est-à-dire: Ce n'est pas exactement déterministe ce que vous perdrez à la suite de la panne de courant. Je reconnais que mettre vos fichiers binaires ou d'autres données importantes en lecture seule sur une partition séparée en lecture seule permet de s'assurer qu'ils ne peuvent pas être jetés par erreur à cause d'une correction fsck dans les structures du système de fichiers. Au minimum, les mettre dans un sous-répertoire différent de la racine que là où les données R/W est tenue aidera. Mais dans les deux cas, si vous prenez en charge les mises à jour logicielles, vous devez quand même avoir un schéma pour traiter les zones "en lecture seule".

Dans notre application, nous maintenons une paire de répertoires pour des choses comme les binaires et le système est configuré pour démarrer à partir de l'une des deux zones. Au cours des mises à jour logicielles, nous mettons à jour le premier répertoire, synchronisons tout sur le média et vérifions les sommes de contrôle MD5 sur le disque avant de passer à la mise à jour de la seconde copie. Pendant le 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 courir le fsck après un certain nombre de remises à zéro, 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 devrait être synchronisée avec vos données (fichiers). Mais comme Jeff mentionné, il ne garantit pas la couche au-dessus du système de fichiers. Cela signifie que vous obtenez toujours des fichiers "corrompus", car certains des enregistrements n'ont probablement pas été écrits dans le système de fichiers.

Je ne suis pas sûr de quel périphérique embarqué vous utilisez, mais à quelle fréquence est-il redémarré? Si le redémarrage est contrôlé, vous pouvez toujours faire "sync; sync; sync" avant de redémarrer.

J'ai utilisé les FC moi-même pendant 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 l'avantage de celui-ci. Pour chaque donnée/fichier du système de fichiers, des métadonnées y sont associées. La plupart du temps, si vous ne changez pas les fichiers, par exemple. binary/system files, alors cette métadonnée ne devrait pas changer. Sauf si vous avez un matériel défectueux, comme les mots croisés écrire & lire, ces fichiers en lecture seule devraient être sûrs.

La plupart des problèmes surviennent lorsque vous avez quelque chose d'inscriptible, et peu importe où vous mettez cela, cela peut causer des problèmes si l'application ne le gère pas correctement.

Espérons que ça aide.