Configuration ext4 «sûre» pour les systèmes fonctionnant sans surveillance

18

J'ai un système exécutant linux qui doit fonctionner sans surveillance pendant de longues périodes. Le système utilise une carte CF industrielle pour le stockage. La plupart du temps, il n'y a pas d'écritures à flasher, bien que de temps en temps certaines données / paramètres de configuration puissent être modifiés. Le système doit être résistant aux pannes de courant.

Je voudrais utiliser ext4 pour cela. Quelle est la meilleure façon de configurer ext4 pour ce type de configuration? Gardant à l'esprit que:

  • Les performances ne sont pas du tout un problème (surtout les performances d'écriture)
  • En cas de panne de courant, le système doit toujours démarrer dans un état propre, même si cela signifie que les données écrites au cours des dernières secondes sont perdues
  • S'il est possible d'éviter fsck, tant mieux.

(Je suis conscient de cette question connexe: Empêchez la corruption des données sur le lecteur ext4 / Linux en cas de panne de courant )

ext4 Grodriguez
la source

Réponses:

11

J'ai travaillé à la construction d'un système d'automatisation sur les bateaux, et il y avait une condition préalable: à chaque instant la puissance pouvait baisser et tout devait repartir correctement.

Ma solution était de construire un système initramfs basé sur Gentoo, avec seulement un dossier rw pour les applications et les configurations (c'est l'approche utilisée par tous les fournisseurs de routeurs / pare-feu). Cette solution ajoute une couche supplémentaire de complexité lors des mises à niveau du système, mais vous assure que le système démarrera TOUJOURS.

Concernant votre question spécifique, vous devriez garder le journal EXT4 activé pour avoir un fsck plus rapide (de quelques secods), utiliser l' option de montage data = journal , baisser l' option commit ou utiliser l' option sync pour garder les tampons toujours vides.

Réfs: http://www.kernel.org/doc/Documentation/filesystems/ext4.txt

Giovanni Toraldo
la source
Bien! Si l'application n'écrit pas trop de données, vous devriez être satisfait de l'option de synchronisation.
Giovanni Toraldo
1
Le meilleur endroit à regarder est la documentation du noyau Linux: kernel.org/doc/Documentation/filesystems/ext4.txt Activer data = journal et commit = nrsec pour minimiser toute perte de données potentielle (* == par défaut)
Giovanni Toraldo
Les validations chronométrées sont certainement utiles - je crois que vous ne pouvez descendre qu'à des intervalles de 1 seconde (bien qu'avec une pénalité de performance MAJEURE pour les opérations intensives en écriture), mais si vous ne pouvez pas vous permettre 1 seconde de perte de données, vous avez de plus gros problèmes;)
voretaq7
2
l'un des principaux effets positifs de la journalisation est que la récupération après un crash est une question de relecture des dernières modifications non validées, ce qui est vraiment plus rapide que la vérification du volume entier pour des incohérences. Si c'est votre problème majeur, alors vous devriez opter pour l'EXT4 par défaut et être heureux.
Giovanni Toraldo
1
@Grodriguez "perdre" des données peut aller de "Le fichier n'est plus là" à "Pourquoi y a-t-il un morceau de noyau dans ma base de données?" - Tout dépend de ce qui est "perdu" :)
voretaq7
12

Je préfacerai ceci en disant qu'en ce qui me concerne, EXT (dans toutes ses incarnations) est un système de fichiers assez horrible - j'ai vu des cas plus " intéressants " de corruption de système de fichiers dans le nombre relativement petit de Linux / EXT {2,3,4} systèmes que j'ai administrés que dans le nombre relativement important de systèmes de fichiers non EXT que j'ai eu l'occasion d'utiliser.
Si possible, essayez de choisir un système de fichiers plus robuste. Vous vous remercierez quand l'inévitable se produira.

Cela étant dit et tous mes préjugés personnels à l'air libre et écartés, EXT4 a trois fonctionnalités auxquelles je peux penser qui pourraient vous aider:

  • La journalisation
    EXT4 peut être un système de fichiers journalisé, si vous le souhaitez. Activez la fonction de journalisation (et définissez spécifiquement le mode de journalisation des données sur journalvia tune2fsou comme option de montage).
    Cela entraîne un impact sur les performances, car toutes les données doivent être écrites dans le journal EXT avant d'être «validées» dans le système de fichiers (chaque écriture se produit essentiellement deux fois), mais cela garantit que vous pouvez toujours récupérer dans la mesure où une relecture du journal vous permettra de problèmes.

  • SYNCMontages hronous
    Lorsque la sécurité est primordiale, le montage d'un système de fichiers avec l' syncoption est toujours une bonne idée. Cela force toutes les écritures sur le disque immédiatement - encore une fois, c'est un coup sûr pour les performances, mais une bonne idée si vous vous attendez à des pannes de courant ou à des étrangers aléatoires tirant sur la carte CF.

  • Limitez autant que possible les systèmes de fichiers inscriptibles. Celui-ci n'est pas spécifique à EXT, mais la philosophie Linux trop courante de "créer une seule grande partition racine et y jeter tout" est franchement stupide . Créer une structure de système de fichiers approprié ( /, /var, /usr, /home, etc ...), et monter le plus grand nombre des systèmes de fichiers en lecture seule possible.
    C'était un conseil commun pour les systèmes Unix pour des raisons de sécurité, mais dans votre cas, il présente un avantage supplémentaire: vous ne pouvez pas corrompre un système de fichiers si vous ne pouvez pas y écrire.

voretaq7
la source
La fonctionnalité des montages entièrement synchrones n'est pas équivalente à un simple appel syncaprès chaque écriture - Les montages synchrones ne reviendront pas (ou du moins ne devraient pas) revenir d'un appel d'écriture du système de fichiers jusqu'à ce que les données soient sur le disque. L'appel syncvidera toutes les écritures en attente, mais il reste une fenêtre (aussi courte soit-elle) entre le retour de l'écriture et votre appel aux syncretours pendant lequel les données peuvent ne pas encore être écrites sur le disque.
voretaq7
Quel système de fichiers recommandez-vous? Pouvez-vous quantifier vos expériences?
Mark Wagner
@embobo mes expériences sont entièrement anecdotiques: je n'ai jamais testé la famille EXT de systèmes de fichiers, mais un incident qui me vient à l'esprit est quand j'ai eu un serveur Squid souffrant de "Où sont passés tous mes inodes?!?" - le système de fichiers a été piétiné et, d'une manière ou d'une autre, marqué comme propre, mais chaque inode a été en quelque sorte laissé dans un état revendiqué mais jamais référencé. Le fsck pour corriger ce désordre particulier était positivement EPIC (nous avons fini par faire un nouveau FS). Ce jour-là, j'ai perdu toute confiance dans la famille de systèmes de fichiers EXT.
voretaq7
@Grodriguez Re: Journalisation, les trois options sont data=journal(ce que j'ai décrit ci-dessus), data=ordered(les métadonnées sont journalisées. Les données sont validées sur le disque avant que les métadonnées ne soient validées dans le système de fichiers), et data=writeback(ce qui n'est en fait pas de journalisation / protection des données - Mauvaises choses peut se produire après un crash, comme des fichiers indésirables au milieu des fichiers). Je crois que orderedc'est la valeur par défaut sur la plupart des distributions Linux de nos jours ...
voretaq7
2
En plus de "Limiter autant que possible les systèmes de fichiers inscriptibles": Dans debian wiki est un guide pour faire exactement cela avec de nombreux exemples sur les démons qui nécessitent un traitement spécial. Il devrait également être valable pour la plupart des autres distributions: wiki.debian.org/ReadonlyRoot
krissi
7

EXT4 ne semble pas être le meilleur choix pour votre système; Je suggérerais de regarder un système de fichiers à structure logarithmique. Ceux-ci fonctionnent en traitant les données comme un flux constant de mises à jour d'écriture par rapport à un flux virtuel, avec un pointeur qui pointe la dernière «tête». Les mises à jour se produisent en écrivant des données et des métadonnées dans le stockage, puis en mettant à jour le pointeur. En cas de plantage après l'écriture mais avant la mise à jour du pointeur, les dernières données sont perdues mais le système de fichiers est cohérent.

Deux systèmes de fichiers candidats sont LogFS et NILFS . Les deux sont disponibles dans le noyau Linux principal.

Steve Smith
la source
1

Je suis intrigué par l'appareil que vous construisez. Vous recherchez la fiabilité d'un périphérique intégré tout en utilisant un système de fichiers qui n'est pas vraiment adapté.

Ext4 (et sa famille) est un beau système de fichiers à usage général avec (je suppose) plusieurs milliards d'heures d'utilisation sur du matériel et des cas d'utilisation variés. Cependant, ce que vous demandez ne correspond pas vraiment à ext4. Les pointeurs de voretaq7 et Giovanni vous aideront à tirer le meilleur parti de l'utilisation d'ext4 si vous le devez, mais la vraie réponse est d'utiliser quelque chose de plus adapté à vos besoins. Steve vous a donné quelques options. Si vous continuez à tirer le pouvoir d'un FS ext4, vous finirez par avoir des dégâts.

S'il s'agit d'un système unique que vous construisez, vous devez choisir d'utiliser quelque chose de plus approprié ou accepter qu'il y aura des problèmes à un moment donné. Il peut ne s'agir que d'une panne de courant sur 100 ou de 1 sur 1000. Cela pourrait suffire pour que vous preniez le risque et l'appareil pourrait probablement fonctionner pendant une longue période (des années) sans aucune intervention manuelle.

S'il s'agit d'un produit que vous avez l'intention de déployer / commercialiser à grande échelle, vous avez le choix d'utiliser quelque chose de plus approprié. Ou vous prenez la décision commerciale de prendre en charge un pourcentage des appareils qui seront briques chaque année et vous aurez besoin d'un remplacement ou d'une intervention manuelle pour les récupérer.

goo
la source