Je dois tester la résilience de certains codes de lecture/écriture pour du matériel embarqué. Comment pourrais-je sacrifier quelques cartes SD et casser plusieurs secteurs connus pour une étude contrôlée ?
La seule chose à laquelle je peux penser est d'écraser un seul secteur plusieurs millions de fois. Je me demande si un script Linux badblocks peut être créé pour exécuter son test destructeur sur un seul secteur de manière répétée pendant plusieurs heures.
Peut-être que ce n'est pas la direction que vous vouliez, mais j'ai constaté que retirer ma carte SD pendant que ma radio ou mon ordinateur portable était en train de lire garantit un crash de la carte SD environ 1 fois sur 5 ou 1 fois sur 10. Il semble que les cartes ne fonctionnent pas bien lorsqu'on leur retire l'alimentation pendant une lecture et probablement des écritures. Après avoir lu les commentaires de Robert Calhoun ci-dessous, je pense que cela pourrait endommager le FAT. Bien que je ne comprenne pas pourquoi la simple lecture provoque un crash - il ne devrait pas y avoir d'écriture en cours?
La zone d'amorçage principale FAT32 du Master Boot Record est probablement la plus susceptible aux abus, car, sur un plan logique, elle doit toujours être au même endroit. (Peut-être que cela est géré par le remappage souple des secteurs défectueux, mais je suis quelque peu sceptique que cela soit implémenté sur tout le matériel.) Donc, vous pourriez exécuter sfdisk en boucle et voir si vous pouvez la mettre en péril de cette manière.
Mais je vais vous demander de faire tout ce que vous pouvez pour améliorer la fiabilité du matériel, plutôt que d'essayer de gérer un matériel défectueux en logiciel. Le problème est que les cartes SD tombent en panne de toutes sortes de manières étranges. Elles deviennent illisibles, ininscriptibles, elles donnent de mauvaises données, elles prennent du temps pendant les opérations, etc. Essayer de prédire toutes les façons dont une carte peut tomber en panne est très difficile.
Voici l'un de mes échecs préférés, "mode de grosse donnée" :
Les cartes SD sont des produits grand public de commodité qui sont soumis à une pression de coût énorme. Les pièces changent rapidement et il est difficile de trouver des fiches techniques. Les produits contrefaits ne sont pas rares. Pour du stockage bon marché, elles sont imbattables, mais alors que les SSD font de la fiabilité une priorité, la priorité pour les cartes SD est la vitesse, la capacité et le coût (probablement pas dans cet ordre).
Votre première ligne de défense est d'utiliser une pièce eMMC soudable avec une vraie fiche technique d'un fabricant réputé au lieu d'une carte SD amovible. Oui, elles coûtent plus cher par Go, mais la pièce sera en production pendant une plus longue période, et au moins vous savez ce que vous obtenez. Souder la pièce évite également tout un tas de problèmes potentiels (cartes retirées pendant les écritures, mauvais contact électrique, etc.) avec une carte amovible.
Si votre produit nécessite un stockage amovible, ou s'il est tout simplement trop tard pour changer quelque chose, envisagez de dépenser l'argent supplémentaire pour des cartes de qualité "industrielle", ou considérez-les comme des objets jetables. Ce que nous faisons (sous linux) est de fsck la carte au démarrage et de la reformater si des erreurs sont signalées, car reformater est acceptable dans ce cas d'utilisation. Ensuite, nous fsck à nouveau. Si cela signale toujours des erreurs après le reformatage, nous la retournons au fournisseur et remplaçons le matériel par une version plus récente utilisant de l'eMMC.
Bonne chance !
Si votre carte SD est formatée en FAT32, vous pouvez hex-éditer les 2 FATs et marquer un secteur comme défectueux avec le bon code hexadécimal. Il s'agit simplement d'une astuce si vous voulez tester logiquement un logiciel censé trouver un secteur défectueux à cet endroit précis ; cela n'endommagera pas votre carte SD non plus, un reformatage la ramènera à un état normal.
Je me demande si un script Linux badblocks peut être créé pour exécuter son test destructeur sur un seul secteur de manière répétée pendant plusieurs heures.
Sur un seul secteur - non, car le code de nivellement d'usure à l'intérieur de la carte SD va remapper les blocs logiques partout.
Mais vous pouvez facilement exécuter badblocks -w dans une boucle jusqu'à ce qu'il provoque l'apparition de certains blocs défectueux. Quelque chose comme ceci devrait fonctionner :
while badblocks -w /dev/xx; do :; doneen supposant que badblocks renvoie 0 si aucun bloc défectueux n'a été détecté et != 0 sinon (la page de manuel ne le dit pas et je n'ai pas vérifié le code source.)
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
