Pourquoi ne peut-on pas fsck une partition montée ?

Le problème de base est que le vérificateur du système de fichiers n'est généralement pas une partie intégrante du système de fichiers. Au lieu de cela, c'est un programme séparé qui lit et écrit sur le même disque que le code du système de fichiers dans le 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 potentiellement modifient) les mêmes données (le disque), mais elles ne se coordonnent d'aucune manière. Le résultat, comme d'autres l'ont souligné, est 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 fantaisistes si le système de fichiers du noyau modifie quelque chose que le vérificateur n'attend pas.

Il existe quelques systèmes de fichiers avec des vérificateurs spécifiquement conçus pour être exécutés "en ligne" (c'est-à-dire lorsque le système de fichiers est actif). Les nouvelles versions de FFS/UFS font cela en exécutant fsck contre un instantané récent du système de fichiers (une copie en lecture seule, point dans le temps, réplique en écriture différée). S'il trouve des problèmes, tels que des incohérences dans les cartes d'allocation, il les corrige via un appel système, plutôt que d'écrire 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 absurde, même avec fsck en mode lecture seule. Le système de fichiers changera sous fsck, et les données en mémoire que fsck met en cache à partir du système de fichiers deviendront invalides (et donc fsck constatera une incohérence). 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. Exécuter 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, ferait en sorte que le noyau voit des structures de système de fichiers changer de manière inattendue en dessous. Ce serait également mauvais.

Outre le fait que cela pourrait probablement tuer votre débit E/S, si le système de fichiers est modifié pendant qu'il est vérifié par fsck, il n'y a aucun moyen pour fsck de suivre les modifications et de signaler les incohérences.

Certains systèmes de fichiers comme XFS vous permettent d'effectuer la vérification de la cohérence alors que le système de fichiers est monté en lecture-écriture, avec l'avertissement que des erreurs fictives seront probablement signalées. xfs_check recommande de démonter le système de fichiers ou de le monter en lecture seule avant d'effectuer la vérification.

Eh bien, le point de fsck est de signaler les incohérences du système de fichiers, c'est-à-dire les invariants violés.

Cependant, bon nombre de ces vérifications impliquent plus d'une structure de système de fichiers. Si quelqu'un modifie le système de fichiers (écrit des données), ces structures peuvent être temporairement désynchronisées. fsck verrait cela comme une incohérence, même si ce n'est pas vraiment un problème. fsck n'a aucun moyen de dire si une incohérence n'est que temporaire, ou un problème permanent qui nécessite une correction. Donc cela ne peut pas fonctionner (Sauf si un SE est conçu spécifiquement pour permettre une vérification en ligne. Certains le font, mais ce n'est pas le cas d'ext3).