Empêchez la corruption des données sur le disque ext4 / Linux en cas de panne de courant

J'ai quelques cartes intégrées exécutant le bios d'American Megatrends avec Linux intégré comme système d'exploitation. Le problème que j'ai, c'est que les idées de flash industriels seront corrompues en cas de coupure de courant. Je les ai formatés en ext4. Chaque fois que cela se produit, je peux généralement réparer le flash avec fsck, mais cela ne sera pas possible dans nos déploiements. J'ai entendu dire que la désactivation de la mise en cache en écriture devrait aider, mais je ne sais pas comment le faire. De plus, y a-t-il autre chose que je devrais faire?

Plus d'informations

Le lecteur est un module flash 4 Go. J'ai une partition qui est ext4. Le système d'exploitation est installé sur cette partition et grub est mon chargeur de démarrage.

fdisk -l affiche / dev / sda comme module flash avec / dev / sda1 comme partition principale.

Après une coupure de courant, je ne peux généralement pas le faire entièrement via les scripts de démarrage.

Lorsque je monte le lecteur sur un autre PC, je lance fsck / dev / sda1. Il affiche toujours des messages comme

"zero datetime on node 1553 ... fix (y)?"

Je les répare et ça démarre bien jusqu'à la prochaine coupure de courant.

Quand j'arriverai au bureau demain, je publierai la sortie réelle de fdisk -l

C'est tout ce que je sais sur le fonctionnement du système. Je ne suis pas un gars des systèmes, je suis un ingénieur logiciel qui a l'habitude de se retrouver dans des situations difficiles en dehors de sa description de travail. Je sais formater des disques, installer un chargeur de démarrage, écrire des logiciels et pirater un système d'exploitation.

Voici la sortie de dumpe2fs

#sudo dumpe2fs /dev/sda1
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name:   VideoServer
Last mounted on:          /
Filesystem UUID:          9cba62b0-8038-4913-be30-8eb211b23d78
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              245760
Block count:              977949
Reserved block count:     48896
Free blocks:              158584
Free inodes:              102920
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      239
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Fri Feb  4 15:12:00 2011
Last mount time:          Sun Oct  2 23:48:37 2011
Last write time:          Mon Oct  3 16:34:01 2011
Mount count:              2
Maximum mount count:      26
Last checked:             Tue Oct  4 07:44:50 2011
Check interval:           15552000 (6 months)
Next check after:         Sun Apr  1 07:44:50 2012
Lifetime writes:          21 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      249d2b79-1e20-49a3-b324-6cb631294a63
Journal backup:           inode blocks

Le cache d'écriture n'a généralement rien à voir avec le BIOS, la plupart du temps il n'y a pas d'option pour changer les paramètres de cache de disque. Avec Linux, l'utilisation hdparm -W 0devrait aider.

Le paramètre est persistant, donc si vous n'avez pas hdparm avec lequel jouer dans vos systèmes de production, vous devriez pouvoir désactiver le cache d'écriture de disque sur un autre système et rebrancher le disque.

BTW: J'appuierais l'idée d'un système de fichiers racine non accessible en écriture (pour que votre système puisse démarrer dans une sorte de "mode de récupération" et permettre un accès à distance même si le système de fichiers accessible en écriture n'est pas montable pour une raison quelconque). Et si vous pouvez changer la conception matérielle, pensez à utiliser des périphériques mtd au lieu de disques IDE / SATA avec un système de fichiers compatible flash comme jffs2 . Nous utilisons cette combinaison avec plusieurs appareils intégrés (principalement des solutions de routeur VPN sur le terrain) depuis plusieurs années avec de bons résultats.

Mise à jour: la racine de votre problème semble être que vous utilisez un système de fichiers ext4 avec la journalisation désactivée - has_journalest absent de la Filesystem featuresliste. Arrêtez tous les services, vérifiez si quelque chose a encore des fichiers ouverts en utilisant lsof +f -- /, remontez votre partition racine en lecture seule mount -o remount,ro /, activez le journal avec tune2fs -O has_journal /dev/sda1et configurez le mode de journal "ordonné" comme option de montage par défaut en utilisant tune2fs -o journal_data_ordered /dev/sda1- vous devrez exécutez fsck (de préférence à partir d'un système de secours) et remontez root / reboot après cette opération.

Avec ces paramètres en place, les métadonnées sont garanties d'être récupérables à partir du journal même en cas de panne de courant soudaine. Les données réelles sont également écrites de manière cohérente sur le disque, bien que vous puissiez voir des données de plusieurs secondes avant la panne de courant perdue au démarrage. Si cela n'est pas acceptable, vous pourriez envisager d'utiliser l' tune2fs -o journal_data /dev/sda1option de montage avec votre système de fichiers - cela inclurait toutes les données écrites sur le disque dans le journal - cela vous donnerait évidemment une meilleure cohérence des données mais au prix d'une pénalité de performance et d'un niveau d'usure plus élevé sur votre SSD.

La suggestion de cache d'écriture est un bon début, mais cela ressemble à un défaut de conception architecturale. Sur un système embarqué, le flash interne ne doit probablement PAS être monté R / W sauf dans de rares circonstances. Vous devriez vraiment faire la plupart du travail dans un système de fichiers en mémoire et synchroniser les modifications sur le flash RW lors d'une commande utilisateur ou d'un intervalle régulier. Il est vraiment rare qu'un système embarqué utilise un système de fichiers normal (comme ext4) en mode rw pendant le fonctionnement normal. S'il y a une exigence d'application où vous avez besoin de beaucoup d'espace de stockage, vous devriez envisager d'avoir votre partition système différente et de la concevoir de telle sorte que la partition de données puisse être fsck -y'ed dans le cadre du démarrage.

Si vous avez besoin de points de départ, je regarderais comment les gens configurent des systèmes Linux sans disque:

http://frank.harvard.edu/~coldwell/diskless/

et commencer à partir de là. L'idée générale est que les fichiers binaires et les données de votre système peuvent être montés en lecture seule afin que votre système de fichiers ne soit pas corrompu. Cependant, vous devez être capable d'écrire dans certaines zones, vous avez donc besoin de quelque chose pour généralement stocker le système de fichiers / tmp, / var / tmp. Même si certaines choses doivent être accessibles en écriture, il vous suffit de créer un script pour monter la partition en tant que r + w, puis de valider les modifications, puis de revenir en lecture seule.

Un très bon exemple de cela est le matériel Cyclades, son Linux intégré et chaque fois que vous apportez des modifications de configuration, vous devez exécuter un script de sauvegarde qui rebondit réellement les configurations et les écrit sur le flash.