Comment puis-je optimiser ext4 pour la fiabilité?

Comme ext4 a été présenté comme plus fiable que ext3 avec les journaux de blocs, y a-t-il une chance de le supposer 100% fiable? Que se passe-t-il si vous activez la journalisation de bloc sur celui-ci, qui est désactivé par défaut?

Comme guide d'un ami pour expliquer mon cas plus en détail: J'ai un périphérique Linux intégré, après l'installation, le clavier et le moniteur sont détachés et cela fonctionne de manière autonome.

Mon devoir est de m'assurer qu'il dispose d'un système de fichiers fiable, donc en cas d'erreur, il n'y a aucun moyen de corriger manuellement les erreurs sur l'appareil. Je ne peux pas forcer mon client à utiliser un ups avec chaque appareil pour garantir l'absence de panne par coupure de courant.

Qu'est-ce que ext4 peut m'offrir en plus de la journalisation par blocs?

Merci d'avance.

filesystem ext4

— amin
source

Je sais que j'ai des compromis permettant des fonctionnalités telles que la journalisation de bloc, mais je suis attaché à la fiabilité et je suis prêt à payer pour cela

— amin

Voir aussi: serverfault.com/questions/244095/how-to-make-ext4-more-reliable , fermé pour être trop ambigu.

— Olli

oui j'ai posé ma question là-bas et il n'y avait aucune aide vient de fermer! mon système linux est un système intégré sans moniteur ni clavier. donc je veux qu'il soit plus fiable en cas de panne de courant, etc ... je sais que la journalisation des blocs est un moyen mais je veux savoir s'il y a plus d'options. je ne peux pas proposer à mon client d'avoir des ups pour chaque appareil.

— amin

@amin Les informations sur votre cas d'utilisation seraient plus utiles dans votre question, c'est probablement pourquoi elles ont été fermées pour être trop ambiguë; ajoutez plus d'informations à votre question!

— Jorge Castro

La question est trop vague. Que signifie «100% fiable»? En supposant que par "bloc jounrnal" vous voulez dire data = journal, alors ce n'est qu'une énorme perte de temps. Le FS est intrinsèquement fiable; un journal s'assure que vous n'avez pas à attendre un long fsck après un crash.

— psusi

Réponses:

Non. Vous ne pouvez jamais supposer que quelque chose est fiable à 100%.

Les systèmes de fichiers de journalisation minimisent la perte de données en cas de panne inattendue. Étendues et barrières aident encore plus, mais ne peuvent pas éliminer tous les problèmes associés. Personnellement, je n'ai jamais subi de perte de données en raison d'une corruption du système de fichiers lors de l'utilisation de systèmes de fichiers de journalisation.

En outre, la journalisation n'est pas désactivée par défaut.

Voici un bon aperçu de ext4 et de ses améliorations: http://kernelnewbies.org/Ext4

— djeikyb
source

+1 pour "vous ne pouvez jamais supposer que quelque chose est fiable à 100%"

— Lekensteyn

comme Comparison_of_file_systems journaling bloc est désactivé alors que des métadonnées journalisées est, que ce compromis entre la fiabilité et la vitesse

— amin

Je viens d'avoir un redémarrage du serveur afin de trouver une corruption de données massive sur ext4 où les fichiers contiennent des données non valides. Cela ne pouvait pas se produire sur zfs ou btrfs car les données ont des sommes de contrôle.

— user239558

Une nouvelle fonctionnalité ajoutée à ext4 et introduite avec le noyau 3.5 est ce que l'on appelle les `` sommes de contrôle des métadonnées '', qui est une autre fonctionnalité d'ext4 censée améliorer la fiabilité et l'intégrité de la structure du système de fichiers.

L'implémentation globale est bien expliquée chez les débutants du noyau :

Les systèmes de fichiers modernes tels que ZFS et Btrfs ont prouvé que garantir l'intégrité du système de fichiers à l'aide de sommes de contrôle est une fonctionnalité intéressante. Ext4 a ajouté la possibilité de stocker des sommes de contrôle de divers champs de métadonnées. Chaque fois qu'un champ de métadonnées est lu, la somme de contrôle des données lues est comparée aux sommes de contrôle stockées, si elles sont différentes, cela signifie que les données sont corrompues (notez que cette fonctionnalité ne couvre pas les données, seulement les structures de métadonnées internes et il n'a pas de capacités "d'auto-guérison").

Tout système de fichiers ext4 peut être mis à niveau pour utiliser des sommes de contrôle à l'aide de la commande "tune2fs -O metadata_csum" ou "mkfs -O metadata_csum" au moment de la création. Une fois que cette fonctionnalité est activée dans un système de fichiers, les noyaux plus anciens sans prise en charge de la somme de contrôle ne pourront la monter qu'en mode lecture seule.

Des articles tels que celui-ci sur kernel.org expliquent en détail de manière très détaillée comment l'utilisation des sommes de contrôle des métadonnées peut empêcher les métadonnées corrompues d'endommager la structure du système de fichiers.

Cependant, l'article prévient également que:

Le code de somme de contrôle des métadonnées a commencé à entrer dans la ligne principale sous Linux 3.5, et à partir de la version 3.7-rc1, il subit des tests utilisateur. Ce code n'est pas encore solide.

Il n'est pas activé par défaut dans Ubuntu 12.10, et il est probablement préférable de ne pas l'activer pour le moment après les récents problèmes avec le système de fichiers ext4, comme indiqué ici .

Vous pouvez désactiver l'allocation différée sous ext4 (nodelalloc), ce qui augmenterait considérablement la probabilité de récupérer plus de données si / quand vous souffriez d'une mise hors tension pendant une écriture, mais cela se ferait au prix d'une fragmentation plus importante du fichier. système au fil du temps.

— user3495444
source