Il est bien connu que vous ne devriez jamais fsck une partition montée. Je peux comprendre que cela puisse facilement entraîner une corruption si le système de fichiers est écrit par fsck (par exemple, l'option -a est utilisée), mais pourquoi les vérifications en lecture seule ne peuvent-elles pas être exécutées sur des disques montés?
Réponses:
De:
http://linux.die.net/man/8/fsck.ext3
« Notez qu'en général il n'est pas sûr de fonctionner e2fscksur les systèmes de fichiers montés. La seule exception est si l' -noption est spécifiée, et -c, -lou les -Loptions ne sont pas précisées. Cependant, même s'il est sûr de le faire, les résultats imprimés par e2fsckdes non valide si le système de fichiers est monté. Si le système vous e2fsckdemande si vous devez ou non vérifier un système de fichiers monté, la seule réponse correcte est "non". Seuls les experts qui savent vraiment ce qu'ils font doivent envisager de répondre à cette question dans toute autre question. façon. "
Le problème fondamental est que le vérificateur de système de fichiers ne fait (généralement) pas partie du système de fichiers. Au lieu de cela, il s’agit d’un programme séparé qui lit et écrit sur le même disque que le code du système de fichiers du noyau. Par conséquent, si vous exécutez fsck sur un système de fichiers actif, vous avez deux entités différentes qui lisent (et modifient éventuellement) les mêmes données (le disque), mais elles ne se coordonnent en aucune manière. Comme d'autres l'ont fait remarquer, il en résulte que la plupart des vérificateurs s'attendent à ce que personne d'autre ne modifie les métadonnées du système de fichiers pendant leur exécution. Ils seront confus et / ou signaleront des erreurs parasites si le système de fichiers du noyau modifie quelque chose auquel le vérificateur ne s'attend pas.
Il existe quelques systèmes de fichiers dotés de vérificateurs explicitement conçus pour être exécutés "en ligne" (c'est-à-dire lorsque le système de fichiers est actif). Les versions les plus récentes de FFS / UFS le font en exécutant fsck sur un instantané récent du système de fichiers (réplica en lecture seule, à point dans le temps, avec copie sur écriture). S'il détecte des problèmes, tels que des incohérences dans les mappes de bits d'allocation, il les corrige via un appel système, plutôt qu'en écrivant sur le disque brut. Cela lui permet de se coordonner avec le système de fichiers actif.
Le WAFL de NetApp dispose également d'un outil de vérification en ligne. Il y en a probablement d'autres.
Exécuter fsck sur une partition montée en lecture-écriture serait idiot, même avec fsck en mode lecture seule. Le système de fichiers changera sous fsck et les données en mémoire que caches fsck à partir du système de fichiers deviendront invalides (ce qui entraînera une incohérence dans fsck). Vous pouvez exécuter fsck sur un système de fichiers monté en lecture seule en mode lecture seule et obtenir des résultats valides. L'exécution de fsck en mode lecture / écriture sur un système de fichiers monté en lecture seule, si fsck apporte des modifications au système de fichiers au cours de son exécution, le noyau verra les structures du système de fichiers se modifier de manière inattendue. Ce serait aussi mauvais.
Mis à part le fait que votre débit d'E / S serait probablement annulé, si le système de fichiers est modifié pendant qu'il est en train d'être fsck, alors fsck ne pourrait pas garder trace des modifications et signaler les incohérences.
Certains systèmes de fichiers, tels que XFS, vous permettent de vérifier la cohérence du système lorsque celui-ci est monté en lecture-écriture. Il convient toutefois de signaler que de fausses erreurs risquent d'être signalées. xfs_checkrecommande de démonter le système de fichiers ou de le monter en lecture seule avant de procéder à la vérification.
Eh bien, le but de fsck est de signaler les incohérences du système de fichiers, qui sont des invariants violés.
Cependant, beaucoup de ces contrôles impliquent plus d'une structure de FS. Si quelqu'un modifie le service de stockage (écriture de données), ces structures peuvent être temporairement désynchronisées. fsck y verrait une incohérence, même si ce n’est pas vraiment un problème. fsck n'a aucun moyen de savoir si une incohérence est juste temporaire ou si un problème permanent doit être corrigé. Cela ne peut donc pas fonctionner (à moins qu'un FS ne soit spécifiquement conçu pour permettre la vérification en ligne. Certains le font, mais pas Ext3).
Vous pouvez, tout comme vous pouvez insérer votre main dans un mélangeur en mouvement et éventuellement ne pas vous blesser, ou tout simplement, vous pouvez sauter d'un bâtiment haut tout en visant le petit tas de coussins que vous avez disposé sur le trottoir.
Mais pourquoi voudriez-vous, mis à part tester votre propre mortalité? Parce que votre patron va certainement le tester à nouveau lorsqu'il découvrira POURQUOI le serveur de messagerie ne reconnaîtra pas le lecteur racine maintenant.