Utilisez les cartes SD en toute sécurité lorsque l'alimentation peut être coupée à tout moment


10

Nous travaillons sur un petit système Linux embarqué (2.6.35-ish) avec un petit périphérique NAND interne pour le système d'exploitation et les applications (250-500Meg) et une carte SD avec des cartes SD SDHC 8 Go pour les données.

L'alimentation de l'unité peut être coupée à tout moment.

Le système doit stocker des données sur des cartes SD. Ces données sont assez importantes ... c'est tout le but du système. Les systèmes sont généralement entièrement déconnectés de tout réseau dans des emplacements distants et les données sont récupérées via sneakernet toutes les 4 à 8 semaines.

Actuellement, nous avons simplement VFAT sur les cartes SD. C'était principalement pour que les premiers clients de test puissent facilement copier les données manuellement sur leurs ordinateurs portables Win7.

Cependant, je crains maintenant que ce ne soit qu'une question de temps jusqu'à ce qu'une panne de courant au mauvais moment entraîne une perte de données.

Quelle est la meilleure façon de configurer un tel système pour éviter la perte de données? JFFS2 ressemble à ce que je voudrais en termes d'écriture de données (et les besoins de performances ne sont pas du tout élevés), mais cela semble assez délicat d'utiliser block2mtd, etc. Je ne sais pas non plus comment le nivellement d'usure de la carte interagira avec ça.

Quelle est la meilleure façon de procéder?

ÉDITER

Je pense maintenant à quitter le système de fichiers VFAT et à allouer des fichiers de taille journalière à la fois, remplis de 0xFF, ce qui devrait limiter considérablement l'exposition aux pannes de cycle d'alimentation. Je ne pouvais alors ajouter que des enregistrements dans ces blocs précréés, et j'espère que les cartes SD ne sont pas si stupides qu'elles effaceraient / porteraient des écritures de niveau dans les régions 0xFF.

Je peux utiliser noatime, mais existe-t-il un équivalent VFAT nomtime pour empêcher les écritures dans le champ d'heure modifié? J'aurais besoin d'un moyen pour empêcher toute mise à jour des métadonnées jusqu'à ce qu'un fichier d'un nouveau jour soit créé.

EDIT 2

Quelqu'un sur l'échange de pile électronique m'a rappelé qu'il y avait aussi des données ECC sur NAND, donc il n'y a aucun moyen d'empêcher la nécessité d'un effacement.

Alors, JFFS2 via block2mtd serait-il approprié dans cette situation?

EDIT 3

C'est pire que ce que je pensais. Les cartes SD que je possède effaceront les blocs de données même si vous écrivez exactement le même contenu sur le disque. Les blocs d'effacement font 64 Ko, et c'est trop grand pour retarder entièrement les écritures. Je vais stocker jusqu'à 128 Ko de données en flash NAND (dont je peux contrôler le comportement d'écriture), dans une sorte de journal, puis écrire des blocs de 128 Ko dans un fichier aligné à 128 Ko dans une partition VFAT sur la carte SD (dans cas où les autres cartes SD ont 128KB effaçables).


1
"j'espère que les cartes SD ne sont pas si stupides ..." <--- ROFLOL. Pas probable!
derobert

Jusqu'à ce que vous trouviez une solution complète au problème que vous avez, utilisez la synccommande après chaque écriture sur la carte SD, elle écrirait les bits immédiatement après les avoir modifiés / créés sans les stocker dans la RAM afin que vos modifications soient au moins sur la carte et ne serait pas allé par la perte de puissance.
Hanan N.

syncaggraverait probablement les choses, car cela augmente la fraction de temps pendant laquelle les métadonnées sont en cours de mise à jour.
Ben Voigt

Réponses:


5

Eh bien, la façon dont vous pouvez résoudre ce problème est de résoudre le problème «l'alimentation peut être coupée à tout moment». Est-il impossible d'ajouter même une minute de batterie?

Alternativement, vous pourriez peut-être utiliser deux cartes SD. Écrivez les données sur une carte, synchronisez, écrivez sur l'autre. Chaque bloc de vos données aurait besoin d'une somme de contrôle et d'un numéro de bloc, mais même avec quelques pannes de courant assez malchanceuses, l'une des cartes devrait être correcte.

Votre problème de base va être le nivellement de l'usure sur les cartes SD, dont AFAIK dépend du fournisseur de la carte (et peut-être même du lot, ils peuvent le changer à tout moment). Il ne gère probablement pas correctement la panne de courant. Et selon ce qu'il fait, cela peut ne pas simplement signifier corrompre le bloc sur lequel vous écrivez.

  1. Supposons une carte trivialement petite: 3 blocs (flash). Le bloc 1 a reçu plus d'écritures que 2 ou 3. J'appellerai les blocs physiques par numéro, et les blocs logiques A, B, C par lettre. À l'heure actuelle, A = 1, B = 2, C = 3.
  2. Vous émettez une écriture pour bloquer le bloc A. La carte SD est comme aha! nous avons besoin de niveler l'usure ici, sinon le bloc 1 va s'user avant 2 et 3. Il décide d'échanger les blocs 1 et 2.
  3. Il lit le bloc 1 en position RAM i (sur la carte SD, pas la RAM système). Il met à jour la partie que vous souhaitez modifier.
  4. Il lit le bloc 2 en position RAM II
  5. Il efface le bloc 1
  6. Il écrit la position RAM ii dans le bloc 1.
  7. Il met à jour la table de mappage pour dire B = 1
  8. Il efface le bloc 2.
  9. Il écrit la position RAM i dans le bloc 2.
  10. Il met à jour la table de mappage pour dire A = 2

Bien sûr, "met à jour la table de mappage" n'est pas toujours trivial. Et l'ordre de 5 à 10 pourrait être différent (s'ils sont tous terminés, cela n'a pas d'importance, eh bien les effacements doivent venir avant les écritures, bien sûr). Mais une panne de courant se produit, vous pouvez vous retrouver avec non seulement A corrompu (comme vous vous y attendez) mais aussi B. Ou, si une panne de courant se produit pendant une mise à jour de mappage, qui sait quel type de corruption cela provoquera.


1
Ces unités doivent vivre dans des environnements relativement difficiles pendant de nombreuses années et une fois installées, elles seront expédiées dans divers pays pour lesquels nous préférons ne pas avoir à qualifier les batteries. Nous abandonnerions probablement MMC / SD et créerions notre propre solution NAND-flash avant d'utiliser une batterie.
darron

Eh bien, dans notre cas, la solution «réparer le« courant peut être coupé à tout moment »» se résume à «empêcher les conducteurs de camions de s'endormir derrière le volant et de pénétrer dans nos appareils». "Un camion s'est écrasé" est en fait le mode de défaillance le plus courant.
SF.

1
Une minute de batterie ne devrait pas être nécessaire. La quantité d'énergie nécessaire pour démonter une carte SD en toute sécurité doit être bien dans la plage qu'un condensateur peut stocker.
Ben Voigt

4

Quelque chose de similaire a été discuté dans electronics.stackexchange.com: Comment protéger la carte SD contre les pannes de courant inattendues?

Une réponse latérale qui fonctionne en tandem avec les solutions logicielles est de regarder le matériel (il y avait une question sur ESE à ce sujet aussi, mais je ne la trouve pas maintenant; il ne s'agissait pas strictement de cartes SD, juste de dispositifs qui perdent de la puissance) et comment le détecter et agir en conséquence).

L'histoire est la suivante: vous n'avez peut-être pas d'alimentation par batterie, mais votre alimentation possède de très gros condensateurs pour lisser l'alimentation. Fondamentalement, le courant ne s'arrête pas. La tension diminue. Il y a probablement un circuit intégré / circuit de protection contre les baisses de tension qui affirme le signal RESET sur votre système intégré lorsque la tension chute en dessous d'un certain point. Les cartes mères PC en ont également, et elles répondent au signal «POWEROK» de l'alimentation. Cela signifie que, lorsque l'alimentation est coupée, l'ordinateur est arrêté de force quelques millisecondes avant que la tension ne tombe en dessous des niveaux de sécurité. Pendant ce temps, les périphériques comme les cartes SD sont toujours sous tension, mais il n'y a plus de transactions provenant de l'ordinateur.

Il est très probable qu'une carte SD ait suffisamment de temps pour terminer toutes les transactions en attente, y compris le nivellement de l'usure, avant que son alimentation ne s'éteigne. Améliorer votre alimentation avec un condensateur suffisamment grand ou en utiliser un à proximité de la carte SD peut vous aider à le faire, mais vous pouvez toujours expérimenter votre plate-forme telle quelle. Il est fort probable qu'il conserve l'énergie pendant suffisamment de temps.

Si l'aspect matériel du problème n'est pas un problème, vous pouvez résoudre les problèmes uniquement logiciels. Les avantages de derobert à utiliser deux cartes pour la redondance ne sont pas mauvais, et l'utilisation d'un système de fichiers standard comme VFAT court moins de risque de confondre les algorithmes de nivellement d'usure de la carte.

Quoi qu'il en soit, il se pourrait bien que vous n'ayez pas autant de problème. En supposant qu'un bloc sur votre carte peut survivre à 100 écritures (conservateur - mais essayez d'obtenir des cartes de bonne qualité!), Et en utilisant des cartes de 8 Go, vous aurez écrit 800 Go au moment de la mort du premier bloc (statistiquement parlant, bien sûr).


La question a été lancée parce que je recevais déjà une corruption massive de la carte SD lors des événements de mise hors tension. Assez souvent, en fait. Peut-être qu'un événement de panne de courant sur 20 a été catastrophique, et peut-être qu'un sur quatre a causé au moins QUELQUES dégâts. J'ai finalement changé pour stocker la valeur d'une journée de données sur le flash NAND interne, et copier sur SD à minuit (une opération d'une seconde environ). Je cherche à améliorer les choses à l'avenir. J'ai déjà 400 uF de capuchons sur le rail ... pas assez, apparemment ... peut-être que la baisse de tension n'est pas gérée correctement.
darron

C'est un taux d'incidence assez élevé! Il est temps d'obtenir les sondes de l'oscilloscope et de voir cela en action, il me semble. Bien qu'il soit probable que vous puissiez le contourner dans le logiciel, la meilleure façon en termes de consommation d'énergie est de vous assurer que vous n'avez pas de problèmes matériels. Peut-être pourriez-vous couvrir vos paris et poser des questions sur electronics.stackexchange.com également?
Alexios

@darron, quelle solution avez-vous trouvée pour votre problème de stockage de carte SD? Ecrivez-vous toujours à NANDFlash puis copiez-vous une fois par jour? J'ai une conception avec une carte SD comme RFS principal (pas de NANDFlash séparé) et je vois des problèmes de corruption de données, à la fois avec et sans coupure de courant soudaine.
fred basset

4

Nous avons eu un problème avec notre SD, le système de fichiers racine ext2 étant corrompu en cas de panne de courant inattendue. Tout d'abord, nous faisons fonctionner le système avec un montage racine en lecture seule. Comme nous avions besoin d'un espace de stockage accessible en écriture (mais que nous n'étions pas en train d'enregistrer les données), nous avons configuré une deuxième partition en tant que accessible en écriture. Pour minimiser les dommages FS en cas de panne de courant inattendue, nous en avons fait une partition ext3, même si cela entraînera au moins deux fois plus d'écritures physiques sur la carte. Cette combinaison (mais j'admets que les écritures de notre deuxième partition sont peu fréquentes par rapport à un enregistreur de données) semble fonctionner sans problème. Jusque là. (Systèmes installés depuis environ 30 mois dans des locaux professionnels)


3

Pour la sécurité des données dans un environnement avec la possibilité de coupures de courant et la sécurité globale des données, vous devriez considérer encore plus de points.

N'UTILISEZ PAS de cellules MLC pour le stockage, seules les SLC ont un temps de rétention des données suffisant. Ces cartes SLC peuvent alors avoir un micrologiciel intelligent, certaines ne peuvent en aucun cas être corrompues par une coupure de courant. Ils reconnaissent la coupure de courant en mesurant et en s'assurant que le dernier bloc est complètement écrit.

Ces cartes sont plus chères et un peu plus lentes que les cellules MLC. Voir les fournisseurs comme swissbit pour les cartes.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.