Quand est-ce que fsck est dangereux?

37

Récemment, j'ai vu le système de fichiers racine d'une machine dans un centre de données distant se remonter en lecture seule, en raison de problèmes de cohérence.

Au redémarrage, cette erreur était affichée:

UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)

Après avoir exécuté fsck comme suggéré et accepté les corrections manuellement avec Y, les erreurs ont été corrigées et le système fonctionne désormais correctement.

Maintenant, je pense qu'il serait intéressant que fsck soit configuré pour exécuter et réparer tout automatiquement, car dans certains cas, la seule alternative (comme celle-ci) consiste à se rendre en personne au centre de données distant et à connecter une console à la machine affectée.

Ma question est la suivante: pourquoi fsck demande-t-il par défaut une intervention manuelle? Comment et quand une correction effectuée par un tel programme serait dangereuse? Quels sont les cas où l'administrateur système peut vouloir laisser une correction suggérée de côté pendant un certain temps (pour effectuer d'autres opérations) ou l'annuler complètement?

linux filesystems mount fsck data-consistency scristalli
la source
15
Si les développeurs étaient 100% confiants que l'erreur pourrait être corrigée automatiquement, il ne s'agirait pas d'une erreur en premier lieu.
user253751

Réponses:

42

fsckfait définitivement plus de mal que de bien si le matériel sous-jacent est endommagé; Un mauvais processeur, une mauvaise RAM, un disque dur en train de mourir, un contrôleur de disque qui a mal tourné ... Dans ces cas, plus de corruption est inévitable.

En cas de doute, il est judicieux de simplement prendre une image du disque corrompu avec dd_rescueun autre outil, puis de voir si vous pouvez réparer cette image avec succès. De cette façon, vous avez toujours la configuration d'origine disponible.

Janne Pikkarainen
la source
4
J'ai beaucoup travaillé avec du matériel défaillant et je suis d'accord avec cela. La dernière chose que je veux faire, c'est fsck s'il y a un matériel suspect. J'ai également vu un événement de faible puissance et une récupération ultérieure qui a été considérablement retardée par fsck automatique.
Jorfus
Pour donner un exemple concret: j’ai travaillé sur une machine avec un contrôleur de disque qui "aléatoirement" (environ 1 fois sur 10 ^ 5) transformerait une lecture ou une écriture en bloc XXXXXXYY sur n’importe quel périphérique en une écriture en bloc 000000YY sur le disque dur. premier appareil. C'est-à-dire qu'il envoyait fréquemment des données incorrectes structurées incorrectes et non structurées au secteur de démarrage et diverses structures de système de fichiers critiques du disque de démarrage. Exécuter fsck dans une telle situation (des millions de lectures) peut éliminer toute chance restante de récupérer des données.
Eric Towers
2
1 sur 10 ^ 5, ça fait beaucoup ... ça fait 10 octets à tout moment.
Nelson
1
@ Nelson: C'est en quelque sorte ... L'unité présente des "transferts d'un seul bloc" et non des "octets". Donc, dix blocs bloqués écrivent par million de blocs (et les blocs sont nettement plus grands que les octets).
Eric Towers
21

Vous avez vu un exemple d'utilisation fsck, mais j'ai vu plus de systèmes de fichiers endommagés qu'il ne fonctionnait pas du tout. Si cela fonctionnait de manière entièrement automatique, vous pourriez ne plus avoir aucune chance de faire des choses comme un ddvidage de disque ou quelque chose du genre qui, dans de nombreux cas, serait une excellente idée à faire avant de tenter une réparation.

Ce n'est jamais, jamais une bonne idée d'essayer quelque chose comme ça automatique du tout.

Oh, et les serveurs modernes devraient avoir des consoles distantes ou au moins des systèmes de secours indépendants pour pouvoir effectuer une récupération à partir de quelque chose comme cela sans avoir à trimbaler un rack KVM sur le serveur.

Sven
la source
7
En fait, ce qui n'est pas une bonne idée est de dire " jamais, jamais " comme ça, quand ce n'est pas vrai. Cas d'utilisation judicieux: les partitions principales du serveur peuvent être recréées assez rapidement, en cas de problème. En réalité, les données importantes sont accessibles via un système de fichiers distant, avec la redondance appropriée en place pour ces données. Je préfère prendre le risque de fsck -p /et fsck -p /var, etc., bien travailler et obtenir serveur sans intervention manuelle, et le risque de la petite, risque non nul% de catastrophe majeure à ces partitions que je peux recréer si nécessaire .
TOOGAM
1
Si le système peut être facilement réinstallé, je ne fais que ça ...
Sven
1
Cela prendrait plus longtemps. Les options sont les suivantes: A) Risque de le faire automatiquement. B) Demandez à quelqu'un de dire fsckà lisser, puis tout fonctionne bien. Prend environ 2 minutes, si ça. Temps d'arrêt jusqu'à ce que cela se produise. C) Demandez à quelqu'un de réinstaller le système d'exploitation. Prend 30+ minutes. Vous choisissez l'option C? Peut-être une différence clé est-elle que j'ai fscktravaillé plus de temps que ce que vous citez dans votre réponse. Mon point principal n'était pas la conception du système (ce système bon marché n'utilise pas de console distante), mais le simple fait de dire « jamais, jamais » était une phrase trop forte pour être précise
TOOGAM
Acceptons simplement d'être en désaccord.
Sven
0

Tout d’abord, vous devez comprendre qu’avec les systèmes de fichiers modernes (journalisés), un crash du système ne corrompra pas le système de fichiers et qu’aucune commande fsck ne sera nécessaire au démarrage.

Ext3, Ext4, ZFS, btrfs, xfs et tous les systèmes de fichiers modernes sont cohérents à 100% après un crash ou une réinitialisation du système.

Les FS non journalisés, comme ext2 ou vfat, sont un gros NOGO pour un rootfs système.

Maintenant, si votre système nécessite une commande fsck au démarrage, vous devez vous demander: quelle en était la raison?

Vous devez ensuite examiner les journaux de votre noyau pour savoir quand et ce qui s’est passé. Vous devez également remonter dans les journaux pour rechercher depuis le début de l’erreur. Vous devriez vérifier vos disques avec smartctl. Etc ... Si vous avez besoin d'un fsck sur un fs journalisé, il est pratiquement certain que votre matériel échoue, en supposant que le fs n'a pas été endommagé par un administrateur (avec des outils de niveau bloc comme dd) ou par un bogue.

Il est donc ridicule d’utiliser fsck pour "résoudre" le problème sans rechercher et réparer la cause première (en remplaçant / mettant à niveau le matériel / micrologiciel / logiciel défectueux).

Faire un fsck, terminer la botte et être heureux est pour le moins naïf. Affirmer "le travail de fsck est plus important que ce que vous citez" me fait me demander ce que vous entendez par "travail de fsck". fsck a peut-être ramené votre fs à un état cohérent en perdant certains fichiers et données au cours du processus ... Avez-vous fait une comparaison avec une sauvegarde? Beaucoup de gens perdent des fichiers ou se font corrompre sans le savoir ...

François Scheurer
la source