# [fsck] effacement i-nœuds orphelins

## pti-rem

Bonsoir,

Mon portable a planté (freeze) et j'ai dû le couper avec une pression sur l'extinction 4 secondes.

Je trouve dans mon rc.log (rc boot logging) un passage sur le fsck qui a suivi, au démarrage :

```
 * Executing: /lib64/rc/sh/openrc-run.sh /lib64/rc/sh/openrc-run.sh /etc/init.d/fsck start

 * Checking local filesystems  ...

RACINE : propre, 1370814/27197440 fichiers, 41369464/108773718 blocs

Maison : récupération du journal

Maison: Lors de l'effacement de l'i-noeud orphelin 52042260 (uid=1000, gid=1000, mode=0100600, taille=4568)

Maison: Lors de l'effacement de l'i-noeud orphelin 52038338 (uid=1000, gid=1000, mode=0100600, taille=4644)

Maison: Lors de l'effacement de l'i-noeud orphelin 45092491 (uid=1000, gid=1000, mode=0100644, taille=32768)

Maison: Lors de l'effacement de l'i-noeud orphelin 45092116 (uid=1000, gid=1000, mode=0100600, taille=86136)

Maison: Lors de l'effacement de l'i-noeud orphelin 45090020 (uid=1000, gid=1000, mode=0100600, taille=2)

Maison: Lors de l'effacement de l'i-noeud orphelin 46006700 (uid=1000, gid=1000, mode=0100644, taille=7406)

Maison: Lors de l'effacement de l'i-noeud orphelin 45092031 (uid=1000, gid=1000, mode=0100644, taille=32768)

Maison: Lors de l'effacement de l'i-noeud orphelin 45091807 (uid=1000, gid=1000, mode=0100600, taille=25776)

Maison: Lors de l'effacement de l'i-noeud orphelin 45091707 (uid=1000, gid=1000, mode=0100644, taille=32768)

Maison: Lors de l'effacement de l'i-noeud orphelin 45091697 (uid=1000, gid=1000, mode=0100600, taille=24692)

Maison: Lors de l'effacement de l'i-noeud orphelin 45090872 (uid=1000, gid=1000, mode=0100600, taille=2)

Maison: Lors de l'effacement de l'i-noeud orphelin 46006693 (uid=1000, gid=1000, mode=0100644, taille=7406)

Maison: Lors de l'effacement de l'i-noeud orphelin 45090139 (uid=1000, gid=1000, mode=0100600, taille=65536)

Maison: Lors de l'effacement de l'i-noeud orphelin 45090085 (uid=1000, gid=1000, mode=0100600, taille=65536)

Maison: Lors de l'effacement de l'i-noeud orphelin 45089216 (uid=1000, gid=1000, mode=0100600, taille=65536)

Maison : propre, 585037/61046784 fichiers, 148041552/244157440 blocs [ ok ]
```

Ça veut dire que j'ai perdu des données ou alors qu'il a réussi à rassembler les morceaux avec le journal ?

Comment je peux savoir ce qui aurait pu être altéré ?

Merci

----------

## pti-rem

```
n73sm ~ # find /home -inum 52042260

/home/rem/.cache/google-chrome/Default/Cache/faa08e85316c4623_0

n73sm ~ # find /home -inum 52038338

/home/rem/.cache/google-chrome/Default/Cache/19a5458cac47447c_0

n73sm ~ # find /home -inum 45092491

n73sm ~ # find /home -inum 45092116

/home/rem/.config/google-chrome/Safe Browsing Module Whitelist

n73sm ~ # find /home -inum 45090020

/home/rem/.Xauthority

n73sm ~ # find /home -inum 46006700

n73sm ~ # find /home -inum 45092031

/home/rem/.config/google-chrome/Safe Browsing IP Blacklist

n73sm ~ # find /home -inum 45091807

n73sm ~ # find /home -inum 45091707

/home/rem/.config/google-chrome/SingletonCookie

n73sm ~ # find /home -inum 45091697

/home/rem/.local/share/gvfs-metadata/uuid-71042D7533E91298

n73sm ~ # find /home -inum 45090872

/home/rem/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml

n73sm ~ # find /home -inum 46006693

n73sm ~ # find /home -inum 45090139

/home/rem/.config/google-chrome/Default/Service Worker/ScriptCache/index-dir/the-real-index

n73sm ~ # find /home -inum 45090085

/home/rem/.config/pulse/2040edb644352487bbc224ab56375766-runtime

n73sm ~ # find /home -inum 45089216

/home/rem/.cache/dconf/user
```

----------

## Mr. T.

Salut, pti-rem !

Nous sommes dans une situation comparable : avoir à réparer un système de fichiers.

Je dois vérifier l'état des systèmes de fichiers lors de l'amorçage du système en utilisant l'init intégré dans l'initramfs.

L'extrait de code (le tien) fait notamment référence à OpenRC et /etc/init.d/fsck.

Bref, je crois qu'on peut répondre à ta question en connaissant les commandes exécutées et en comprenant leur résultat.

 Connaître OpenRC/SysVinit.

 Lire le manuel de la commande fsck (e2fsck).

 Étudier le script /etc/init.d/fsck (entre autre).

 Établir une correspondance avec les informations du manuel et l'exécution particulière de /etc/init.d/fsck.

En effet, la réparation est effectuée en exécutant des commandes. Or, un système d'exploitation n'est pas un outil particulier. 

Autrement dit, une personne n'ayant pas conçu le système doit l'appréhender pour agir avec ou pour le maîtriser.

Il semblerait que l'on ne puisse pas connaître le résultat produit en exploitant  seulement "le message" affiché.

On peut supposer grâce aux constatations (suppositions) précédentes que le message fournit des indications permettant d'interpréter le résultat !

----------

## pti-rem

Bonjour helecho,

Tu récapitules un ensemble théorique plutôt "parfait" et que je suis loin de pouvoir appliquer. Je suis un utilisateur avant tout.

Autrement, deux choses ;

Pourquoi mon système s'est gelé ?

Je plaçais les /sys/class/scsi_host/host[012345]/link_power_management_policy de mon portable à la valeur min_power

Le host0 étant mon SSD système (Racine /) et les host1 et host2 un miroir raid1 de mécaniques identiques (Maison /home)

J'ai un port USB3 sur ce portable, et je crois avoir provoqué un écroulement d'alimentation en y branchant des périphériques non alimentés.

Je crois que cet écroulement est l'origine du gel.

Maintenant, je place les valeurs différemment :

```
echo min_power > /sys/class/scsi_host/host0/link_power_management_policy

echo min_power > /sys/class/scsi_host/host1/link_power_management_policy

echo min_power > /sys/class/scsi_host/host2/link_power_management_policy

echo max_performance > /sys/class/scsi_host/host3/link_power_management_policy

echo max_performance > /sys/class/scsi_host/host4/link_power_management_policy

echo max_performance > /sys/class/scsi_host/host5/link_power_management_policy
```

Et ensuite, comment lire une entrée du rc boot logging ?

```
Maison: Lors de l'effacement de l'i-noeud orphelin 52042260 (uid=1000, gid=1000, mode=0100600, taille=4568)
```

"Lors de l'effacement de l'i-noeud orphelin" semblerait indiquer une désallocation de l'i-nœud concerné ; Ce qui reviendrait à dire que mes tests find -inum ne sont pas utiles.

J'ai quand même un « Maison : propre » final et peu d'orphelins libérés.

« une personne n'ayant pas conçu le système doit l'appréhender pour agir avec ou pour le maîtriser »

Plus ou moins, c'est selon... Ou pour partie(s) alors. Il faut en avoir le temps et l'envie aussi.

Il y a des shunts dans l'apprentissage ; en gros, heureusement que l'on est pas seul et que l'on bénéficie parfois d'une aide pratique.

Bon courage pour ta réparation de système de fichiers.

Je ne suis pas contre du tout tes études personnelles.

Merci pour ta réponse.

Bon courage !

----------

## Mr. T.

 *pti-rem wrote:*   

> Il y a des shunts dans l'apprentissage ; en gros, heureusement que l'on est pas seul et que l'on bénéficie parfois d'une aide pratique. 

 

Je suis d'accord avec toi. 

"Lors de l'effacement de l'i-noeud orphelin" est équivalent à "clearing orphaned inode".

Le Web nous informe que l'inode n'est plus associé à un fichier : le fichier pourrait avoir été détruit ou déplacé ?

 *pti-rem wrote:*   

>  "Lors de l'effacement de l'i-noeud orphelin" semblerait indiquer une désallocation de l'i-nœud concerné ; Ce qui reviendrait à dire que mes tests find -inum ne sont pas utiles. 

 

Je crois que les inodes ont été attribué à de nouveaux fichiers (cf. find /home -inum, des répertoires contenant des données temporaires ?? : .cache, .config).

Édition : L'article Journaling file system est intéressant ++ ext4.

TERMINOLOGIE :

HANG ~ FREEZE : BLOCAGE [https://en.wikipedia.org/wiki/Hang_(computing)]

SYTEM CRASH : PLANTAGE INFORMATIQUE (GDT)

----------

