Selon Patrice Karatchentzeff <patrice.karatchentzeff-alplog@???>:
> Le Fri, 5 Dec 2003 11:14:38 +0100
> ymartin59@??? écrivait :
>
> > Cette partition ext3 a été rempli au maximum... 0 d'espace libre
> > malgré la réserve 'root' alors qu'aucun processus root n'écrive
> > dessus. Première bizarrerie !
>
> Un classique : un rm sur un fichier entrain d'être ouvert et rempli.
> Résultat : plus de fichier apparent (avec ls) mais un fichier qui
> continue à grossir...
Non, non. Ce fichier correspond à une redirection de stdout/stderr d'un
processus cron. Jamais de rm, que des trunk/append !
Avec l'espace en réserve sur un filesystem, on ne peut jamais arriver à
zéro (sauf si un processus root écrit dessus), c'est juste ? Alors pourquoi
cela m'est arrivé ?
> > Ce fichier est un fichier de log - des trunk et append - c'est tout.
> > Est-ce que cela peut expliquer le problème ? Y-a-t'il un bug dans le
> > filesystem ? Comment corriger si le fsck ne change rien ?
>
> De mémoire, un lsof pour savoir qui fait cela, plus kill pid devrait
> déjà stopper la progression.
Ou fuser par exemple. Comme je l'ai dis précédemment le fichier n'est plus
en cours d'écriture quand je fais le ls/du:
ls -l
total 508696
-rw-r--r-- 1 tester xxx 779865 Dec 7 18:35 autotests.log
$ du -k autotests.log
508612 autotests.log
$ fuser autotests.log
=> rien
Et je me dis que si le filesystem est corrompu, qu'un fichier mappé par
un processus peut provoquer un segfault sur une page non allouée.
Que faire pour récupérer un ext3 tout propre sans tout formaté (14 Go !) ?
--
Yves Martin
