Re: [Message erreurs] Micro coupure d'electricité

[to /dev/null <todevnull@tele2.fr>]

Le ven 04/06/2004 Ã 08:15, grillot sebastien a Ãcrit :
> to /dev/null wrote:
> > Le ven 04/06/2004 Ã 01:45, grillot sebastien a Ãcrit :
> > 
> >>Bonsoir,
> >>je viens d'etre "victime" (si je puis dire) d'une micro coupure 
> >>d'electricità et donc forcement d'un arret de mon systeme quelque peut 
> >>rapide... (je suis sous une mandrake 9.1, kernel 2.4.21)
> >>Je viens de rebouter et j'ai eu ces messages etranges lors du "check forced"
> >>"dev/hda6 : clearing orphaned inode 7127042 (uid=501, gid=501, 
> >>node=040755 size = 4096)"
> >>Le message c'est ecrit plusieurs fois avec des legeres variantes a 
> >>l'interieur du message (pas dans la partie entre parenthese) mais je ne 
> >>sais pas combien de fois.
> >>Quelqu'un serait ce que signifie ces message? j'ai un soucis ?
> >>
> > 
> > 
> > Ãa indique un inode (un fichier) qui n'est pas rÃfÃrencà par un
> > rÃpertoire.
> > 
> > C'est une situation tout à fait normal. Par exemple le fichier est
> > occupà par un programme (donc il faut un inode) et il a Ãtà supprimÃ
> > (donc il n'est plus rÃfÃrencà par un rÃpertoire). Dans une telle
> > situation, si le noyau est arrÃtà brutalement (en appuyant sur "reset"
> > par exemple), il reste des inode (fichiers) qui n'ont plus de raison
> > d'Ãtre puisque les programmes qui les utilisaient n'existent plus.
> > 
> > Cette situation peut aussi arriver lors de la suppression d'un fichier
> > et un arret brutal de noyau.
> > Lors de la suppression le noyau fait :
> > 1 - fichier occupà par le programme qui va le supprimer
> > 2 - la rÃfÃrence au fichier par un rÃpertoire est supprimÃ
> > 3 - puis la table des bloques de donnÃes est mise à jours
> > 4 - puis le inode est supprimà et le programme n'occupe plus le fichier.
> > 
> > Si arrÃt du noyau entre 2 et 4 on a "orphaned inode".
> > 
> > Ce n'est pas un problÃme de journalisation d'ext3. 
> > 
> > 
> >>merci bien.
> >>
> >>Seb
> > 
> Commencon par le commencement, merci pour cette explication, ca eclair 
> beaucoup ma lanterne.Cependant, de petites choses m'echappe. Tu dis "Ãa 
> indique un inode (un fichier)" et "le fichier est occupà par un 
> programme (donc il faut un inode)" donc je  ne comprend pas tres bien. 

Il y a la table des inodes. Les inodes reprÃsentent les fichiers
(spÃciaux, normaux, etc...) et aussi les rÃpertoires (mais pas les
fichiers dans le rÃpertoire ! Un rÃpertoire n'est qu'un "rÃpertoire"
d'inode).
Exemple :
numÃro inode
2 : un rÃpertoire
20 : un autre rÃpertoire
25 : un fichier
26 : un autre fichier

jusque là ces rÃpertoires et fichiers sont anonymes (on ne connait pas
leurs noms n'y oà ils sont).
Le inode de numÃro 2 est spÃcial. C'est le rÃpertoire racine (pour
ext[23], je ne connais pas les autres).

Le contenu du inode 2 est :
type : rÃpertoire
son contenu liste des inodes et leur donne un nom :
        num inode : 20, nom tmp
        
Maintenant on connait un des nom pour accÃder à l'inode 20 (il peut en
avoir plusieurs, j'y reviendrais).

Pour chaque inode il y a d'autres informations comme les droits, le
propriÃtaire, la date de derniÃre modification, etc...

Le contenu de l'inode 20 est :
type : rÃpertoire
son contenu liste des inodes et leur donne un nom :
	num inode : 20, nom '.' (c'est lui mÃme)
	num inode : 2, nom '..' (c'est le parent, ici la racine '/')
	num inode : 25, nom 'titi'
	num inode : 26, nom 'toto'

Le rÃpertoire /tmp ne dit pas si 'titi' ou 'toto' sont des fichiers ou
des rÃpertoires. Cette information est dans l'inode.
Pour montrer que le nom du inode est stockà dans le rÃpertoire :
$ cd /tmp
$ ln toto tutu

Le nouveau contenu de /tmp
	num inode : 20, nom '.' (c'est lui mÃme)
	num inode : 2, nom '..' (c'est le parent, ici la racine '/')
	num inode : 25, nom 'titi'
	num inode : 26, nom 'toto'
	num inode : 26, nom 'tutu'

Il y a deux 'pointeurs' vers le inode 26. Le inode 26 peut Ãtre utilisÃ
avec les noms /tmp/toto et /tmp/tutu.
$ cd /tmp
$ ll
25 -rw-rw-r--  1 me me 0 jun  4 09:01 titi
26 -rw-rw-r--  2 me me 0 jun  4 09:01 toto
26 -rw-rw-r--  2 me me 0 jun  4 09:01 tutu
La premiÃre colonne donne le numÃro du inode.
La troisiÃme le nombre de rÃfÃrence vers le inode. Ici on voit qu'il y a
deux rÃfÃrences vers l'inode 26. C'est-Ã-dire deux faÃon d'accÃder au
fichier.
Ce sont strictement les mÃme fichiers.
Exemple :
$ chmod 600 toto
$ ll toto tutu
26 -rw-------  2 me me 0 jun  4 09:01 toto
26 -rw-------  2 me me 0 jun  4 09:01 tutu
$ echo coucou > toto
26 -rw-------  2 me me 7 jun  4 09:05 toto
26 -rw-------  2 me me 7 jun  4 09:05 tutu

Pour supprimer le inode 26, il faut supprimer les deux rÃfÃrences Ã
l'inode :
$ rm -f /tmp/toto /tmp/tutu
C'est à dire qu'il faut que le nombre de rÃfÃrences vers le inode 26
soit à 0. Lorsqu'il est a 0, le noyau supprime le contenu du inode 26
(les rÃfÃrence vers les bloques du disque dure) puis supprime le inode
26 (en rÃalitÃ, il n'est pas supprimÃ, il est seulement indiquà comme
disponible).

J'ouvre le fichier titi et je le laisse ouvert. Par exemple j'utilise le
programme 'less' :
$ less /tmp/titi

Dans un autre terminal je fais :
$ ps ax | grep less
 ps ax | grep less
 3673 pts/2    S      0:00 less titi
$ cd /proc/3673/fd
$ ll
lr-x------  1 me me 64 jun  4 09:06 4 -> /tmp/titi

Je supprime /tmp/titi
$ rm -f /tmp/titi
VÃrification de la suppression :
$ ll /tmp/titi
ls: /tmp/titi: Aucun fichier ou rÃpertoire de ce type

Je regarde les fichiers ouverts par less
$ cd /proc/3673/fd
$ ll
[...]
lr-x------  1 me me 64 jun  4 09:06 4 -> /tmp/titi (deleted)

Le contenu est toujours là donc l'inode aussi. Par contre il n'y plus de
rÃpertoire qui pointe vers ce inode. Il n'est plus possible d'accÃder Ã
son contenu (sauf pour le programme 'less' qui l'a ouvert avant sa
suppression).

Au niveau du systÃme de fichier sur le disque dure, c'est une erreur
(avoir un fichier inaccessible est dÃfinitivement une erreur). Sur le
disque dure, le contenu est toujours là et le inode est marquà comme
'deleted' (et non 'disponible') et le nombre de rÃfÃrence vers le inode
est à 0.

Par contre pour le noyau le inode doit exister puisqu'il est ouvert par
un programme (ici 'less'). Le noyau avant de supprimer un inode vÃrifie
qu'il n'y a plus de rÃfÃrence vers le inode par les rÃpertoires ET par
les programmes.
Il y a donc deux vues du systÃme de fichier. Une, c'est la vue du
systÃme de fichier par le disque dure et l'autre c'est la vue du systÃme
de fichier par noyau. Les deux sont lÃgÃrement diffÃrentes.

Si j'appuie sur "reset", au boot suivant lors de la vÃrification du
disque dure, fsck va voir le inode '26' comme marquà "deleted" et va le
supprimer (puisqu'il n'est plus accessible).

Il y a aussi un autre cas.
Imaginons que j'ai un gros fichier (plus d'un giga octet).
Je fais :
$ rm -f gros_fichier
Le noyau fait :
1 - suppression de la rÃfÃrence dans le rÃpertoire qui pointe sur le
fichier.
2 - si le nombre de rÃfÃrence est à 0 :
        2.1 - marque l'inode comme en cour de suppression.
        2.2 - libÃre les blocks utilisÃs par le inode (cela peut durer
        plusieurs secondes).
        2.3 - supprime l'inode (le marque comme 'disponible').

S'il y a un "reset" (ou une coupure de courant) durant 2.2, il y a
problÃme puisque l'inode existe alors qu'il n'est plus accessible. fsck
corrigera Ãa (finira de libÃrer les blocks et supprimera l'inode).

Enfin, il y a un dernier cas qui est normalement rare sinon c'est un bug
ou un problÃme hardware. Parfois fsck trouve un inode "normal" (pas
marquà "deleted" etc) mais aucun rÃpertoire qui rÃfÃrence ce inode.
Dans ce cas, fsck crÃe une rÃfÃrence vers ce inode dans le rÃpertoire
'lost+found' (perdu trouvÃ). Comme un nom dans 'lost+found' doit Ãtre
"inventÃ", son nom sera '#num_inode'. Par exemple "#26".



> En soit un inode est l'autre nom de "fichier" ou bien un inode est le 
> resultat d'un fichier qui est bloquà par un programe et donc il crÃe un 
> inode ? A la fin tu me dis que ce n'est pas un probleme de 
> journalisation. Pourquoi j'aurais du spontanement penser que c'etait un 
> pbm de journalisation ou bien ce sujet fais un quelconque debat ?
> 

Parce que la journalisation est supposer garantir l'intÃgrità du systÃme
de fichier lors d'un "reset" ou d'une coupure de courant.
Ben non, Ãa ne marche pas toujours.
NÃanmoins, mÃme si le systÃme de fichier est dans un Ãtat "bizarre"
(comme indiquà prÃcÃdemment) tu peux continuer d'utiliser le systÃme de
fichier. Il n'y a pas de risque. Le seul problÃme est d'avoir de la
place disque utilisÃe pour rien.
Dans la pluspart des cas, la journalisation corrige ces problÃmes lors
du montage du systÃme de fichier et sans faire de long fsck.

----------------------------------
Informations, désabonnement, règles, obligations sur la liste Aide-Linux :
http://lists.ze-linux.org/howto_ml.html