C'est l'histoire d'un cluster RedHat (RHCS sous RHEL 4 AS), composé d'une paire de serveurs et d'une baie de disques SCSI en double-attachement pour servir du Zimbra en haute disponibilié (HA comme on dit). Rien que de très standard en fait.

Sauf que, pour une raison que je ne connais pas (enfin si, en partie et ce n'est pas la faute de RHCS), les deux nodes se sont retrouvés à accéder simultanément à la baie. L'un d'entre eux (node2) faisait tourner Zimbra "normalement" tandis que sur le premier (node1), "on" essayait de remonter Zimbra... Et comme "on" n'y arrivait pas, on a rebooté le node1 qui n'a rien trouvé de mieux que d'estimer qu'il était temps de faire un fsck sur la baie de disques (le nombre de mounts nécessaire pour cela étant atteint).

Là où ça a commencé à ne plus aller du tout, c'est qu'on avait en même temps le node2 qui servait du Zimbra et le node1 qui tentait le fsck. J'ai donc fait éteindre le node2 pour ne plus s'occuper que du fsck.

Mais rien à faire...
On lance le fsck, il fait ce qu'il a à faire (d'après les infos qu'il renvoie) et si on le relance juste derrière, il recommence.
Exactement pareil.
Comme si rien n'avait été fait avant.
Et ainsi de suite...

Pour le plaisir, juste le début :

fsck -f -y /dev/cciss/c1d0 
 fsck 1.35 (28-Feb-2004)
 e2fsck 1.35 (28-Feb-2004)
 Resize inode not valid.  Recreate? yes
 
 Pass 1: Checking inodes, blocks, and sizes

Google ne m'a pas beaucoup aidé. J'ai juste appris que je n'étais pas le seul à avoir ce problème de "Resize inode not valid". Quelques utilisateurs de CentOS et surtout des utilisateurs de FC3 et Ghost.

C'est sur une mailing list FC3 que j'ai trouvé une piste d'ailleurs : e2fsck 1.35 est buggé.
Pas juste un peu, carrément buggé, justement dans son support du resize.

Un petit up2date plus tard, je me suis rendu compte qu'en fait RedHat ne le voyait pas de cet oeil-là et considérait que son e2fsck 1.35 était une bonne version, bien stable, bien efficace.

Je hais RedHat.

Donc téléchargement de la dernière version vraiment stable de e2fsprogs puis compilation et lancement de la chose...

 ./e2fsck/e2fsck -f -y /dev/cciss/c1d0 
 e2fsck 1.39 (29-May-2006) 
 Resize inode not valid.  Recreate? yes 
  
 Pass 1: Checking inodes, blocks, and sizes 
  
 Running additional passes to resolve blocks claimed by more than one inode... 
 Pass 1B: Rescanning for multiply-claimed blocks 
 Multiply-claimed block(s) in inode 7: 85 32895 32897 
 Multiply-claimed block(s) in inode 3342426: 32895 32897 85 
 Pass 1C: Scanning directories for inodes with multiply-claimed blocks 
 Pass 1D: Reconciling multiply-claimed blocks 
 (There are 1 inodes containing multiply-claimed blocks.) 
  
 File /logger/db/data/zimbra_logger/raw_logs.MYD (inode #3342426, mod time Thu Jun 28 11:16:49 2007) 
   has 3 multiply-claimed block(s), shared with 1 file(s): 
         <The group descriptor inode> (inode #7, mod time Fri Jun 29 01:32:47 2007) 
 Clone multiply-claimed blocks? yes 
  
 Pass 2: Checking directory structure 
 Pass 3: Checking directory connectivity 
 Pass 4: Checking reference counts 
 Pass 5: Checking group summary information 
 Free blocks count wrong for group #0 (65535, counted=0). 
 Fix? yes 
  
 Free blocks count wrong (69259429, counted=69259430). 
 Fix? yes 
  
  
 zimbra-vol: ***** FILE SYSTEM WAS MODIFIED ***** 
 zimbra-vol: 41327/35848192 files (2.3% non-contiguous), 2426616/71686046 blocks

Et encore une fois (tant que ça marche, je joue)...

 ./e2fsck/e2fsck -f -y /dev/cciss/c1d0 
 e2fsck 1.39 (29-May-2006) 
 Pass 1: Checking inodes, blocks, and sizes 
 Pass 2: Checking directory structure 
 Filesystem contains large files, but lacks LARGE_FILE flag in superblock. 
 Fix? yes 
  
 Pass 3: Checking directory connectivity 
 Pass 4: Checking reference counts 
 Pass 5: Checking group summary information 
  
 zimbra-vol: ***** FILE SYSTEM WAS MODIFIED ***** 
 zimbra-vol: 41327/35848192 files (2.3% non-contiguous), 2426616/71686046 block

Et encore une troisième fois.

#  ./e2fsck/e2fsck -f -y /dev/cciss/c1d0 
 e2fsck 1.39 (29-May-2006) 
 Pass 1: Checking inodes, blocks, and sizes 
 Pass 2: Checking directory structure 
 Pass 3: Checking directory connectivity 
 Pass 4: Checking reference counts 
 Pass 5: Checking group summary information 
 zimbra-vol: 41327/35848192 files (2.3% non-contiguous), 2426616/71686046 blocks

Même pas drôle : ça marche. Vraiment. Proprement. Je hais RedHat.

Un up2date du node2 plus loin (cman pas à jour, donc évidemment le cluster ne se montait pas), tout fonctionne à nouveau...