Système de fichiers de la carte SD résistant à la corruption pour Linux intégré?

Récemment, nous avons eu une situation plutôt déplaisante avec notre client - le "kiosque" basé sur Raspberry Pi utilisé pour afficher des données de télédétection (rien de plus qu'un navigateur en mode kiosque affichant une page Web à mise à jour automatique à partir du serveur de collecte de données) n'a pas pu démarrer en raison de corruption de système de fichiers. Ext4, manuel fsck requis, le système fera partie de la présentation importante de demain, service requis immédiatement. Bien entendu, nous ne pouvons pas demander au client d’arrêter le système correctement lorsqu’il est éteint pour la nuit; le système doit simplement résister à de tels mauvais traitements.

J'aimerais éviter de telles situations à l'avenir et j'aimerais déplacer le système d'exploitation vers un système de fichiers qui empêcherait cela. Il existe de nombreux systèmes de fichiers destinés aux périphériques MTD, pour lesquels leur exécution sur carte SD (un périphérique en mode bloc standard) nécessite de sérieux sauts de cercle. Il existe également d'autres systèmes de fichiers (journalisation, etc.) qui offrent une bonne résistance à la corruption. J'ai encore besoin de voir une comparaison raisonnable de leurs avantages et inconvénients.

Le système de fichiers disponible sous Linux offrirait la meilleure résistance contre la corruption en cas de coupure de courant imprévue et ne nécessiterait pas de sauter par- dessus des obstacles impossibles comme yaffs2 pour pouvoir l'installer en SD.

L'équilibrage de l'usure est un avantage, mais pas une exigence - les cartes SD ont généralement leurs propres mécanismes, même s'ils ne sont pas parfaits, bien que le système devrait être «doux pour le flash» (des systèmes comme NTFS peuvent tuer une carte SD en un mois).

BTRFS offre la meilleure résistance contre la corruption sur une seule carte SD en mode RAID1 avec un nettoyage automatique exécuté toutes les périodes prédéfinies.

Les avantages:

1. conserver la possibilité de RW dans le système de fichiers
2. système de fichiers moderne et complet avec des options très utiles pour un RPi, comme la compression transparente et les instantanés
3. conçu avec la mémoire flash à l'esprit (entre autres)

Voici comment faire:

Je lance RaspberryPi sur ArchARM Linux et ma carte est dans le lecteur SD. Modifiez donc ces instructions en conséquence pour les autres distributions et les interfaces / dev.

Voici un exemple de disposition de partition:

/dev/mmcblk0p1: fat32 boot partition
/dev/mmcblk0p2: to be used as btrfs partition
/dev/mmcblk0p3: to be used as btrfs partition (mirrored with the above)
/dev/mmcblk0p4 (optional): swap

Pour obtenir btrfs dans RAID1, vous créez le système de fichiers comme suit:

mkfs.btrfs -m raid1 -d raid1 /dev/mmcblk0p2 /dev/mmcblk0p3

Ensuite, vous allez rsync -aAXvvoir votre système précédemment sauvegardé.

Pour le faire démarrer à partir de BTRFS dans raid1, vous devez modifier initramfs . Par conséquent, vous devez effectuer les opérations suivantes pendant que votre système fonctionne toujours sur votre ancien système de fichiers.

Framboise n'utilise normalement pas mkinitcpio, vous devez donc l'installer. Ensuite, vous devez ajouter “btrfs” au tableau MODULES dans mkinitcpio.conf et recréer initramfs avec

mkinitcpio -g /boot/initrd -k YOUR_KERNEL_VERSION

Pour savoir quoi taper au lieu de YOUR_KERNEL_VERSION, exécutez

ls /lib/modules

Si vous mettez à jour le noyau, vous DEVEZ recréer initramfs AVANT de redémarrer.

Ensuite, vous devez modifier les fichiers de démarrage de RPi.

Dans cmdline.txt, vous devez avoir

root=/dev/mmcblk0p2 initrd=0x01f00000 rootfstype=btrfs

et dans config.txt, vous devez ajouter

initramfs initrd 0x01f00000

Une fois que vous avez terminé tout cela et démarré avec succès dans votre système btrfs RAID1, il ne vous reste plus qu'à configurer un nettoyage périodique (tous les 3 à 7 jours) avec un timer systemd (préféré) ou un cron (dcron) comme ceci:

btrfs scrub start /

Il fonctionnera sur votre système de fichiers en comparant les sommes de contrôle de tous les fichiers et en les corrigeant (en les remplaçant par la copie correcte) s'il détecte une quelconque corruption.

La combinaison de BTRFS RAID1, de single medium et de Raspberry Pi en fait un joli produit arcane. Il a fallu du temps et du travail pour assembler toutes les pièces, mais le voici.

Bien, le stockage flash est plus souhaitable que le stockage magnétique, pour plusieurs raisons, mais pour cette application, je dirai principalement parce qu'il n'y a pas de pièces mobiles. Cela étant dit, je ne pense pas qu'il existe un système de fichiers «anti-corruption», mais il existe des systèmes de fichiers robustes (ext4 en est un) ainsi que des tactiques permettant de limiter la corruption.

Disque RAM

Si l'image du RPi ne doit pas nécessairement changer et que cela ne semble pas être le cas, si rien n'essaie (ou ne devrait essayer) d'écrire sur le disque, essayez d'utiliser un système de fichiers racine créé pour être décompressé dans la RAM . L'idée ici est que vous avez au démarrage un système de fichiers racine compressé qui est décompressé dans la RAM. Tous les changements se produisent sur le disque RAM, il n'y a donc aucune écriture sur la carte SD, seule la lecture au démarrage. cela devrait réduire le nombre de lectures / écritures sur votre lecteur, tout en préservant sa durée de vie. Ceci est similaire à ce qui est fait lorsque vous démarrez Linux à partir d'un CD et constitue l'une des premières choses qui se produit lorsque Linux démarre .

J'irais autrement et utiliserais simplement un système de fichiers en lecture seule. Je n'obtiens jamais assez mon Raspberry Pi avec un système de fichiers racine en lecture-écriture sur la carte SD. Vous pouvez simplement démarrer votre racine via la commande cmdline (ro) du noyau ou utiliser un initramfs avec piggyback incluant votre système complet.

Les deux sont possibles à créer avec mon système de construction fait maison OpenADK. ( http://www.openadk.org )

Eh bien, le problème que vous rencontrez ici est que l’utilisation d’un système de fichiers "moderne" tel que le fichier ext * risque de détériorer votre carte SD; de mon expérience cela se produit dans l'année, ou l'année suivante si vous prenez le haut de gamme.

Le problème est que les systèmes de fichiers modernes déplacent constamment des blocs pour éviter la fragmentation des données. Ce qui est une bonne chose sur les disques en rotation, où vous voulez que toutes vos données soient assemblées lors du chargement dans le cache. L'inconvénient est qu'il fait plus d'écritures qui ne peuvent pas être mises en cache car le rangement est géré alors qu'il n'y a pas beaucoup d'entrées / sorties.

Cela se produit également lorsque vous gérez beaucoup de journalisation, ce que vous pouvez faire lors du débogage de votre périphérique intégré. Les écritures de journalisation constituent le pire type d'écriture, car de nombreuses écritures minuscules se produisent régulièrement, ce qui génère beaucoup de fragmentation.

Comme vous dites que votre système gère également les données du capteur, il est très probable que vous les stockiez sur le flash au fur et à mesure de leur apparition. Et ils sont aussi mauvais que les données du journal.

Je suis dans le même problème que vous rencontrez, et voici mes conclusions. J'ai essayé de rechercher des cartes SD vendues comme étant "plus robustes", c'est-à-dire capables de gérer plus d'écritures que les autres, mais je n'ai trouvé aucune référence sur le marché qui se concentre sur cela, contrairement à celles du SSD. Comme ils se concentrent tous uniquement sur la vitesse, il est impossible de connaître le nombre d'écritures par bloc de mémoire et la technologie utilisée dans la carte SD.

Cependant, j'ai remarqué que les sandisks de qualité "industrielle" avaient une durée de vie plus longue que les non-noms. Ce qui n’est pas surprenant, lorsque vous payez plus, vous obtenez plus.

Mais au final, avec la journalisation intensive activée, je n’ai trouvé aucune carte SD ayant une durée de vie supérieure à quelques années, une année étant celle où le plus grand nombre de décès survient.

Les solutions que j'ai proposées sont les solutions de @ BigHomie et de @wbx: utilisez un système de fichiers extX en lecture seule (la journalisation n'étant plus nécessaire, vous pouvez même vous replier sur le bon vieil ext2). Et si vous souhaitez conserver les journaux au sein de la session ou écrire des fichiers temporaires, vous pouvez toujours utiliser un RAMDISK.

Il existe des didacticiels et des scripts uniquement qui permettent de renseigner le disque mémoire avec des données contenues dans les parties en lecture seule afin que vous puissiez les modifier pour la session.

NB: Mon expérience a été d’utiliser Angstrom Linux sur un Beaglebone, parmi une série d’essais de 20 capteurs. L'enregistrement de ce système était très détaillé et utilisait le système de journalisation de systemd.

Linux offre de nombreux systèmes de fichiers. ext4 est celui dans lequel j'ai le plus confiance. En cas de doute, ext4 devrait être utilisé pour toute partition montée en lecture-écriture.

Le système de fichiers ext2 est beaucoup plus fragile. C'est un système de fichiers parfaitement adapté aux systèmes capables de le monter en lecture seule ou de le démonter correctement. Mais la corruption est extrêmement probable avec une panne de courant sur ext2 .

L’autre option pourrait être d’envisager jfs même si le système de fichiers jfs n’est pas fiable dans certaines versions de Linux. La corruption est moins probable avec jfs qu'avec ext4 . Jfs est également doté d’un temps de montage rapide et d’un temps de vérification du système de fichiers.