Ara fa cosa d’un mes, el servidor de Pacs de l’Hospital Universitari de Bellvitge, va començar a queixar-se del sistema de fitxers, amb missatges com aquest:
Nov 1 00:35:06 pacsbellvitge01 kernel: init_special_inode: bogus i_mode (136237)
Al rebre el primer mail, ja va fer que em comencés a mirar, quin era exactament el problema, ja que aquesta màquina està en producció amb una base de dades de 23GB, i té muntat a través d’una SAN, un sistema de fitxers EXT3 de 5TB sobre un LVM.
El codi font del kernel, ho deixava ben clar, l’error es llança quan s’arriba a un inode que no se sap el què és (no és un dispositiu de caracter, un de blocs, un fifo, ni un socket), printa aquest missatge, tot dient-nos l’inode en qüestió.
void init_special_inode(struct inode *inode, umode_t mode, dev_t rdev)
{
inode->i_mode = mode;
if (S_ISCHR(mode)) {
inode->i_fop = &def_chr_fops;
inode->i_rdev = rdev;
} else if (S_ISBLK(mode)) {
inode->i_fop = &def_blk_fops;
inode->i_rdev = rdev;
} else if (S_ISFIFO(mode))
inode->i_fop = &def_fifo_fops;
else if (S_ISSOCK(mode))
inode->i_fop = &bad_sock_fops;
else
printk(KERN_DEBUG "init_special_inode: bogus i_mode (%o)n",
mode);
}
Estava clar que s’havia llançar un check del disc.
La millor opció que se’m va acudir, va ser fer un snapshot via LVM per a curar-me en salut per si el fsck em destruïa tot el sistema de fitxers, o feia alguna cosa desagradable, però no vaig poder perquè no tenia Physical Extents lliures, i per a redimensionar el sistema de fitxers per arribar a lliberar-ne, les utilitats m’obligarien a fer un fsck, la qual cosa em tornava a l’estat inicial.
També vaig pensar d’utilitzar un disc USB per afegir un nou dispositiu al LVM, o utilitzar un dispositiu de loopback. D’aquesta manera, segurament tindria prous PE per a l’snapshot, però corria el risc que una vegada fet l’snapshot, no pogués alliberar el disc. Fins on jo se, amb LVM l’única manera de alliberar PE per acabar alliberant un dispositiu, és movent-los cap a un altre dispositius amb PE lliures, i no estic segur si al eliminar l’snapshot s’alliberarien els PE utilitzats.
Al no poder-ho fer, i haver de fer ens canvis sobre el sistema de fitxers en calent, primer em vaig voler assegurar dels canvis que em faria l’fsck, per tant vaig muntar el sistema de fitxers amb només lectura:
mount -o remount,ro /cabina
i vaig llençar un fsck sense permetre que em modifiqués res:
fsck -v -n -C 0 /dev/adaptecfs4500/fs4100_01
Això em va mostrar els canvis que es farien, i al veure que eren raonables, vaig planificar l’actuació per aquest cap de setmana passat, ja que era un dels pocs que la gent de l’Hospital no treballava.
La meva estimació del fsck va ser d’unes 48hores, i l’hagués clavat si no hagués estat perquè en al arribar al 70%, va llançar aquest missatge:
Restarting e2fsck from the beginning...
Això va fer tornar a començar el procés, havent d’esperar 48hores més per acabar. Aquest temps era impensable assumir-lo, ja que el personal de l’hopital necessita el servidor per a poder fer la seva feina diària. Aquí va començar la meva documentació sobre si és possible cancelar un fsck sobre un sistema sense perdre les dades.
Finalment vaig trobar la resposta donada per un dels desenvolupadors de les e2fsprogs, en Teodore Ts’o:
«It is safe to abort fsck while it is scanning the Filesystem.»
Vaig premer el ^C i aparentment tot estava al seu lloc.Com a notes de tot el procediment, dir que sempre és recomanable utilitzar LVM en dispositius amb una sèrie de característiques, ja que en el llarg dels anys, podem necessitar algunes de les seves funcionalitats.
Nov 1 00:35:06 pacsbellvitge01 kernel: init_special_inode: bogus i_mode (136237)
Al rebre el primer mail, ja va fer que em comencés a mirar, quin era exactament el problema, ja que aquesta màquina està en producció amb una base de dades de 23GB, i té muntat a través d’una SAN, un sistema de fitxers EXT3 de 5TB sobre un LVM.
El codi font del kernel, ho deixava ben clar, l’error es llança quan s’arriba a un inode que no se sap el què és (no és un dispositiu de caracter, un de blocs, un fifo, ni un socket), printa aquest missatge, tot dient-nos l’inode en qüestió.
void init_special_inode(struct inode *inode, umode_t mode, dev_t rdev)
{
inode->i_mode = mode;
if (S_ISCHR(mode)) {
inode->i_fop = &def_chr_fops;
inode->i_rdev = rdev;
} else if (S_ISBLK(mode)) {
inode->i_fop = &def_blk_fops;
inode->i_rdev = rdev;
} else if (S_ISFIFO(mode))
inode->i_fop = &def_fifo_fops;
else if (S_ISSOCK(mode))
inode->i_fop = &bad_sock_fops;
else
printk(KERN_DEBUG "init_special_inode: bogus i_mode (%o)n",
mode);
}
Estava clar que s’havia llançar un check del disc.
La millor opció que se’m va acudir, va ser fer un snapshot via LVM per a curar-me en salut per si el fsck em destruïa tot el sistema de fitxers, o feia alguna cosa desagradable, però no vaig poder perquè no tenia Physical Extents lliures, i per a redimensionar el sistema de fitxers per arribar a lliberar-ne, les utilitats m’obligarien a fer un fsck, la qual cosa em tornava a l’estat inicial.
També vaig pensar d’utilitzar un disc USB per afegir un nou dispositiu al LVM, o utilitzar un dispositiu de loopback. D’aquesta manera, segurament tindria prous PE per a l’snapshot, però corria el risc que una vegada fet l’snapshot, no pogués alliberar el disc. Fins on jo se, amb LVM l’única manera de alliberar PE per acabar alliberant un dispositiu, és movent-los cap a un altre dispositius amb PE lliures, i no estic segur si al eliminar l’snapshot s’alliberarien els PE utilitzats.
Al no poder-ho fer, i haver de fer ens canvis sobre el sistema de fitxers en calent, primer em vaig voler assegurar dels canvis que em faria l’fsck, per tant vaig muntar el sistema de fitxers amb només lectura:
mount -o remount,ro /cabina
i vaig llençar un fsck sense permetre que em modifiqués res:
fsck -v -n -C 0 /dev/adaptecfs4500/fs4100_01
Això em va mostrar els canvis que es farien, i al veure que eren raonables, vaig planificar l’actuació per aquest cap de setmana passat, ja que era un dels pocs que la gent de l’Hospital no treballava.
La meva estimació del fsck va ser d’unes 48hores, i l’hagués clavat si no hagués estat perquè en al arribar al 70%, va llançar aquest missatge:
Restarting e2fsck from the beginning...
Això va fer tornar a començar el procés, havent d’esperar 48hores més per acabar. Aquest temps era impensable assumir-lo, ja que el personal de l’hopital necessita el servidor per a poder fer la seva feina diària. Aquí va començar la meva documentació sobre si és possible cancelar un fsck sobre un sistema sense perdre les dades.
Finalment vaig trobar la resposta donada per un dels desenvolupadors de les e2fsprogs, en Teodore Ts’o:
«It is safe to abort fsck while it is scanning the Filesystem.»
Vaig premer el ^C i aparentment tot estava al seu lloc.
Actualització: He fet la prova, i sembla que al crear un snapshot, totes les modificacions es fan als PE del Volum lògic, i el què és mogut als PE de l’snapshot, són les dades velles. Això fa que al eliminar l’snapshot, sigui una acció molt rapida, i alliberi els PE del dispositiu on hi ha l’snapshot.
Nota: Utilitzar LVM en els dispositius amb «xixa», ja que la seva gran maniobravilitat ens pot solucionar molts problemes.
Kaizen lifestyle - Albert Sellarès Blog 