Hier je vous disais de ne jamais relancer un ordinateur sous Linux lorsqu'il est allumé depuis très longtemps sous peine de passer des heures à dire "yes" lors de la récupération de fichiers abîmés qui en fait ne correspondent à rien.
Pour éviter de répondre tout seul, il y a deux possibilités :
- soit faire une réponse affirmative par défaut et tout corriger en automatique. C'est par la commande fsck -y /dev/XXX
- soit faire une réponse négative par défaut, ne rien corriger et voir l'ampleur des erreurs, puis aviser si la correction de tout est réellement faisable ou s'il faut passer outre.
Dans le cas où la correction des erreurs, quand elles sont justifiées, prend trop de temps et que la partition incriminée n'est pas la partition principale, il y a une solution de contournement à laquelle j'ai finalement pensé cette nuit au moment d'aller me coucher après quelques parties de Bejeweled sur iPad.
Cette solution de contournement au blocage des serveurs (et ordinateurs) sous Linux en cas de reboot et de contrôle forcé des partitions est à faire à vos propres risques. Si la partition est réellement HS, ça ne va pas arranger les choses ! en revanche si tout fonctionnait correctement avant le reboot et que vous n'avez pas le temps de patienter, autant ne pas s'en priver.
La solution est simple : désactiver la partition, rebooter l'ordinateur, puis s'y reconnecter pour remonter la partition.
Pour cela, il faut déjà la repérer dans /etc/fstab, la mettre en commentaire (par un dièse en premier caractère), puis relancer l'ordinateur. Normalement il vous rend la main sans se préoccuper de cette partition, sous réserve qu'elle ne soit pas vitale au lancement d'un processus système.
Une fois la machine relancer, se reconnecter dessus, décommenter la ligne dans /etc/fstab, puis lancer simplement un mount /dev/XXX pour remonter la partition.
S'il s'agissait de /home sur un serveur web, il est fortement conseillé de relancer vos serveurs web (Apache, Nginx), de base de données (MySQL,Postgres), de noms (Bind), de courrier (Postfix, Exim), ... pour vous assurer que tout est actif.
Bien entendu au reboot suivant le système retentera la correction d'erreurs et c'est normal. Ce n'est que pour dépanner ponctuellement. N'en abusez pas.
Concernant mon problème, si je l'avais laissé tourner jusqu'au bout, c'est à dire jusqu'au mois ou à l'année prochaine à répondre tout seul aux différentes demandes d'unattached inod, il en aurait traité plus de 69 millions, ce qui aurait probablement rempli la partition en gonflant inutilement le dossier /lost+found créé pour l'occasion. Si je l'avais fait à la main, je pense que mes héritiers y seraient encore, si tant est que j'eusse pris le temps d'en faire pour poursuivre mon oeuvre...
En contournant le problème grâce à mon éclair de génie, j'ai pu reprendre la main sur la machine en moins de 10 minutes alors que ça faisait plus de 14 heures qu'elle était inaccessible !
Comme quoi, de temps en temps il y a des choses qu'on ne devrait pas corriger, pour ne pas stresser ni perdre du temps. C'est aussi ça l'informatique !