Je n'ai pas l'habitude de débrancher le pi dans le sens d'éviter de les arrêter correctement, sauf lorsque j'ai perdu la mise en réseau sur un pi sans tête, auquel cas je suis généralement trop paresseux pour brancher un clavier, etc.
En général, je vérifie toujours que le voyant vert ACT n'est pas allumé à ce stade; pour les modèles récents (ou firmware?), cela sera désactivé lorsque la carte SD n'est pas accessible. C'est ce dont vous voulez vous assurer. À moins que vous ne lui écriviez constamment, cela devrait être assez simple; tant qu'il y a une quantité suffisante d'espace libre dans la RAM libre (disons 50-100 + Mo, selon le contexte), alors les choses qui sont susceptibles d'être réutilisées fréquemment mais qui ne sont pas réellement chargées par un processus à un moment donné sera mis en cache dans la mémoire libre et rechargé à partir de là par le système d'exploitation, pas le véritable support physique. C'est ainsi que fonctionnent tous les systèmes d'exploitation à usage général contemporains.
Si le pi utilise la carte SD, voici quel est le risque minimal : le système de fichiers sur la carte n'est pas synchronisé avec l'état en mémoire. Normalement, ce n'est probablement pas un gros problème; pour commencer, la journalisation du système de fichiers utilisée par défaut sur la plupart des pis pourrait être une défense contre elle, tout comme le fsck qui devrait être appliqué automatiquement au démarrage si le système de fichiers n'a pas été correctement démonté. J'expliquerai pourquoi je dis "pourrait" et non "est" sous peu, car dans ce contexte, je pense que ce n'est souvent pas le cas .
Pour autant que je sache, je ne me suis jamais retrouvé avec une corruption du système de fichiers ou une perte de données en tirant sur la prise, ce que j'ai peut-être fait cent fois ou plus au fil des ans. Cependant, encore une fois, je ne le fais pas habituellement. Si vous le faites plusieurs fois par jour, vous pouvez éventuellement rencontrer le niveau de risque statistique, et il y a un risque potentiellement désagréable.
Voici le PROBLÈME:
Récemment, il m'est venu à l'esprit qu'il y a un problème avec les cartes SD contre lesquelles les mécanismes du système d'exploitation / fichier peuvent être impuissants et qui peuvent expliquer pourquoi certaines personnes semblent avoir des problèmes persistants avec la corruption de FS, en particulier ceux qui se mettent à tirer le cordon quel que soit le système état - par exemple, récemment, quelqu'un ici a prétendu exécuter des modules de calcul où la corruption a laissé les systèmes non démarrables dans ~ 1/40 de ces coupures de courant.
En termes abstraits, sans tenir compte de la nature des cartes SD , cela ne devrait pas se produire même si le système est occupé, car ce qui est le plus susceptible de se corrompre, ce sont les éléments non critiques qui sont en cours d'écriture, pas tout logiciel système qui est effectivement en lecture seule et n'est modifié que lors des mises à jour.
Cela peut arriver si des bits sont jonglés, et ainsi les méta-informations du système de fichiers qui stockent où divers bits sont corrompus. Encore une fois, cependant, journalling et fsck devraient être capables de gérer cela, ce qui nécessite le démarrage du noyau, mais le noyau sur le pi se trouve sur une partition de démarrage distincte qui pourrait aussi bien être démontée pendant l'utilisation (sauf lors de la mise à jour) car rien de tout cela n'est utilisé après le démarrage du système. Cela signifie que les informations sur la partition doivent être, effectivement, incorruptibles, même lorsqu'elles sont montées.
Mais...
Les cartes SD sont une boîte noire pour le système d'exploitation. Il n'y a aucun moyen de s'en sortir. Bien qu'il existe des pilotes spécifiques pour les contrôleurs de carte SD qui font partie du matériel de l'ordinateur (sur le pi, cela fait partie du SoC), il n'existe pas de pilote pour des marques et des modèles de carte différents et spécifiques.
Et pourtant, ils ont tous à l'intérieur des microcontrôleurs qui peuvent fonctionner de manière très différente. 1. C'est ce qui fait de la carte une boîte noire; il interagit avec le système d'exploitation via un protocole SD normalisé, et c'est le dernier point de contrôle dont dispose le système d'exploitation.
L'une des fonctions des cartes SD et des autres supports à semi-conducteurs, qui diffère des disques rotatifs traditionnels, est d'utiliser l'adressage virtuel opaque; ils ne stockent pas d'informations physiquement dans les séquences perçues par le système d'exploitation. C'est surtout une bonne chose, sinon nous pourrions avoir vraiment besoin de pilotes différents pour différentes marques de cartes, etc., et cela permet aux cartes de mettre en œuvre (de manière opaque) un nivellement d'usure , ce qui prolonge considérablement leur durée de vie.
Une autre chose sur laquelle ils comptent est des "blocs d'effacement" relativement grands; lorsque les données d'un bloc doivent être modifiées, le bloc entier est effacé et réécrit. Les systèmes de fichiers font aussi ce genre de chose, bien sûr, mais notez que c'est au niveau du logiciel système, et les problèmes qui en résultent sont exactement les types de problèmes de journalisation et de traitement fsck.
Le nœud du problème le plus insurmontable est que les systèmes de fichiers à l'échelle font cela est généralement beaucoup plus petit que les cartes SD à l'échelle. Si ce n'était pas le cas, vous perdriez beaucoup d'espace de stockage, car un bloc de système de fichiers ne peut contenir que des données d'un seul fichier. Si le bloc fait 2 Mo et qu'il n'y a que quelques ko de données, le reste est perdu. Les blocs du système de fichiers ont donc tendance à varier de 1/2 Kio à 4 Kio.
Il est assez évident que les cartes SD ne le font pas, et en fait, ne le peuvent pas, car le contrôleur d'une carte SD n'a pas conscience des limites telles que "fichier", "système de fichiers" ou même "partition de périphérique". Il traite simplement les blocs de données que le système d'exploitation souhaite, via une couche opaque à l'intérieur d'une boîte noire où tout pourrait se produire au niveau physique.
L'une des raisons pour lesquelles il est évident (à part les cartes de base "ne pouvaient pas faire cela en premier lieu") est que ces blocs sont souvent assez grands, mais les cartes semblent faire un travail décent en utilisant tout l'espace. Un bloc d'effacement peut avoir plusieurs mégaoctets . De plus, les détails sont exclusifs. Bien qu'il puisse y avoir des mécanismes par lesquels le système d'exploitation peut demander la taille du bloc d'effacement à la carte, la carte n'a pas à fournir cela, elle peut mentir à ce sujet et il deviendrait absurde si le système d'exploitation tentait de l'utiliser.
Il en résulte que depuis:
Le contrôleur de carte SD n'a aucune idée de ce que les données appartiennent "à juste titre" où dans le sens de systèmes de fichiers et de partitions cohérents, et,
La carte SD est une boîte noire dans laquelle le système d'exploitation ne peut pas vraiment voir,
Ensuite, ce qui se trouve dans un bloc d'effacement de 1 Mo donné, où une carte contient plusieurs partitions utilisant 4 Ko ou des blocs de système de fichiers plus petits, est forcément arbitraire une fois que la carte a été suffisamment utilisée (et peut-être même si elle n'a pas été beaucoup utilisée à tout). Cela est probablement vrai même si vous essayez de forcer le système d'exploitation à utiliser des tailles de bloc plus grandes / correspondantes; ils finiront mal alignés.
Donc:
Si l'alimentation est coupée alors que la carte SD est au milieu de la modification d' un bloc, qui pourrait entraîner la perte d'un volume relativement important de données arbitraires qui pourraient être quelque chose de la carte. Il peut s'agir d'informations marquées "en lecture seule". Il peut s'agir d'informations provenant d'une partition qui n'est même pas montée et, évidemment, de la partition de démarrage la plus inutilisée.
Si cela se produit et que la carte n'a pas son propre système de sauvegarde (ce que certains peuvent avoir, mais je suis sûr que la plupart n'en ont pas), alors vous pourriez envisager une situation FUBAR. Journalling ne protège pas contre la corruption de taille de MB aléatoire qui ne reconnaît même pas les limites de partition. Ou fsck.
Ou, puisque le matériel de la carte est généralement propriétaire, il pourrait y avoir autre chose que des logiciels produits par le fabricant de la carte - en supposant que cela soit plausible. Je n'en ai jamais entendu parler. Cela rendrait les cartes plus compliquées, plus chères et plus compliquées à utiliser. Ce n'est pas le but.
Autrement dit, les cartes SD ne sont pas destinées à être utilisées de manière fiable de cette façon . Ils sont bon marché et très pratiques, mais c'est le résultat d'un compromis dans le protocole: en général, il n'y a aucune garantie d'intégrité des données pour quoi que ce soit sur la carte si vous coupez arbitrairement le pouvoir.
Qu'est-ce qui peut mal tourner en débranchant simplement le Pi? Dois-je commencer simplement à débrancher? Remarque: dans ce cas, je ne suis pas trop inquiet de la perte de données.
Il n'endommagera pas physiquement le pi, non, il suffit de prendre garde que la "perte de données" pourrait s'étendre à une "carte inutile" qui doit être complètement reformatée. Cependant, je dirais que la chance de cela si vous le faites avec le voyant vert ACT éteint est très faible.
- Cela peut être important si l'on considère pourquoi certaines marques / modèles de cartes spécifiques sont clairement pires que d'autres pour certaines personnes. Malheureusement, alors que deux cartes qui sont identifiées de manière identique peuvent être identiques en termes de caractéristiques déclarées (taille, vitesse, etc.), les fabricants ne sont pas tenus de les rendre véritablement identiques à 100% en termes de composants.