Ce matin, j'ai fait la connerie de rebooter un serveur Linux qui tournait depuis 757 jours... forcément, l'OS a estimé qu'il était temps de vérifier les disques durs.
La machine a été relancée à 11 heures 30, 8 heures plus tard ce n'est toujours pas reparti normalement.
Cette mésaventure me rappelle qu'il ne faut JAMAIS RELANCERUN ORDINATEUR SOUS LINUX qui ne l'a pas été depuis longtemps si on a autre chose à faire de la journée !
Du coup, j'en suis arrivé à finalement faire un check du disque pourobtenir une longue liste inexploitable d'erreurs :
Unattached inode 7031217 Connect to /lost+found<y>? yes
Inode 7031217 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 7031218 Connect to /lost+found<y>? yes
Inode 7031218 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 7031219 Connect to /lost+found<y>? yes
Inode 7031219 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 7031220 Connect to /lost+found<y>? yes
Inode 7031220 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 7031221 Connect to /lost+found<y>? yes
Inode 7031221 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 7031222 Connect to /lost+found<y>? yes
Inode 7031222 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 7031223 Connect to /lost+found<y>? yes
Inode 7031223 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 7031224 Connect to /lost+found<y>? yes
Inode 7031224 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 7031225 Connect to /lost+found<y>? yes
Chers développeurs Linux, franchement, qui répond autre chose que Yes à ce genre de question ? En quoi de savoir que l'inode 7031224 a un soucis peut-il aider l'utilisateur à choisir de le réparer ou de ne pas le réparer ? Et franchement, vous croyez pas que lorsqu'on a des disques de plusieurs centaines de Go qui servent beaucoup en écriture / lecture, création et suppression de fichiers, on va s'emmerder à répondre "y" pendant toute la journée ?
Heureusement qu'il y a des options d'automatisation des réponses, mais la logique dans le fait même de poser ces questions m'échappera toujours. A la limite, ajoutez un "toujours répondre yes" ou "toujours répondre no" en plus du yes / no dans les réponses posibles à tel type de question. Ca évitera qu'il la pose sans cesse et sans que l'on sache vraiment à quoi ça correspond au final ni l'impact réel sur l'état du système de fichiers une fois le massacre terminé.
C'est quand même dingue de voir une machine qui tourne bien toute seule, qu'on relance, et qui refuse ensuite de tourner sous prétexte qu'elle s'est mélangé les pinceaux dans son système de fichiers.
C'est du ext3, j'espère que ext4 sera moins verbeux ou plus efficace dans ces micmacs. Réponse à cette espérance d'ici un an ou deux, quand je rebooterai mes premiers serveurs l'utilisant...