Le 10.03.2005 17:19:38, Bertrand Lemaître a écrit :
Bonjour, Sous testing avec noyau 2.4.27, la commande df ne me renvoyait rien. Je n'ai pas vu d'erreur dans les logs. Pourtant tout semblait fonctionner correctement, excepté que je ne pouvais plus installer de paquet (message: plus de place libre sous /var/lib). /var est un fs de type ext3 et j'ai opté pour faire e2fsck /var Mauvais choix, car le système était monté, et j'ai quand même forcé le check, puis comme il me proposait de supprimer des inodes non utilisé, j'ai répondu "yes" en cascade. Résultat : plusieurs "yes" qui n'étaient pas à faire <<Passe 2: vérification de la structure répertoire Entrée 'lib' dans / (2) a détruire/non utilisé inode 98113. Effacer<y>? yes (pour oui) Entrée 'cache' dans / (2) a détruire/non utilisé inode 179873. Effacer<y>? yes (pour oui) Entrée 'backups' dans / (2) a détruire/non utilisé inode 228929. Effacer<y>? yes (pour oui)>> Comment récupérer ces entrées (inodes) ? Avec debugfs il renvoie /dev/sda7: Bad magic number in super-block while opening filesystem Qu'est que j'aurais dû faire lorsque df, ne me renvoyait plus rien ?
Arrêter le système, faire de la place, relancer le système.
Non, mais il faut l'utiliser sur un sustème de fichier démonté ou read-only.e2fsck est il à proscrire quand on est en ext3 ?
Pas dans ce cas. La journalisation permet de ganer (beaucoup) de temps lors de la vérification des systèmes de fichiers. Elle ne permet pas d'assurer une meilleure intégrité du système de fichiers.Est-ce que la journalisation (ext3) peut m'aider à quelquechose ?
Merci pour votre aide dans ces moments de galère
Dans votre cas, il faut essayer de récupérer ce qui peut l'être.Si vous avez une partition séparée pour ce système de fichier, dd_rescue vous permettra d'en faire une image de sauvegarde avant de la tripoter. Ensuite, vous pouvez tenter de récupérer un superblock valable sur votre système de fichiers.
Et enfin de l'agrandir. Jean-Luc
Attachment:
pgph7ucbsuI3y.pgp
Description: PGP signature