[filesystem] les sept gigaoctets fantomes (résolu)

[Emericn6k]

Énigme du jour...
Je veux comprendre ce qui prend tant de place sur ma partition racine.
Dans mon filesystem, à part les points de montage /home et /media, tout est sur la partition en question.

Un df / (ou autre) me donne donc

Code : Tout sélectionner

21.6 / 24.4 Go occupés.

Ensuite quand je vais voir dossier par dossier (en root pour être sûr de ne rien rater et par interface graphique, dolphin en l'occurrence) :

Code : Tout sélectionner

bin 6 Mo
boot 30 Mo
dev ~0
etc 6 Mo
lib (et lib32 et lib64) 120 Mo
lost+found ~0
mnt ~0
opt 1.3 Go
proc 128 To (là faut qu'on m'explique... je n'en tiens pas compte du coup)
root 1 Mo
run ~0
sbin 12 Mo
srv ~0
sys 600 Mo
tmp 2 Mo (parfois bien plus, mais de ttes façons ça ne dépasse jamais 2Go quand ça compile, disons)
usr 6.1 Go
var 5.1 Go

Un calcul d'une folle complexité donne un total de 14 Go (un peu moins même), si je retire proc.

Questions donc :
-où peuvent donc être passés mes 7 Go?
-proc, ça marche comment? y a des trucs vraiment stockés sur le disque?

Bon j'imagine bien sûr que ça dépend nettement du type de filesystem. Là c'est du reiserfs - sans doute pas optimal, mais ça fait bientôt 4 ans que ça tourne avec
Ça faisait un moment que ça me trottait dans la tête mais comme jusqu'ici ça ne posait pas problème, je n'ai pas cherché plus tôt...

Toute ma gratitude au premier qui saura m'expliquer ça


EDIT : dans /proc, tout fait 0 octets sauf /proc/kcore qui fait les 128 téras en question et ça a l'air d'être un problème connu. Donc il ne me reste qu'à retrouver les 7 Go.

[benjarobin]

Donne la sortie en root de : du -sh /* 2>/dev/null
Ainsi que la sortie de : df -h

[tuxce]

EDIT : dans /proc, tout fait 0 octets sauf /proc/kcore qui fait les 128 téras en question et ça a l'air d'être un problème connu. Donc il ne me reste qu'à retrouver les 7 Go. [/color]

C'est pas un problème, /proc comme /sys, /dev, /tmp ... sont des pseudo système de fichiers.
Pour avoir le bon compte (-x permet de rester sur le même système de fichier):

Code : Tout sélectionner

du -xchd1 /

La sortie de df -h comme dit par benjarobin nous sera utile (toujours donner les vraies sorties, c'est pas qu'on croit pas, mais on peut mal interpréter des sorties par manque d'expérience.)

[Emericn6k]

Effectivement c'est encore mieux avec des commandes propres.

la sortie de df :

Code : Tout sélectionner

Sys. fich.                                             Taille Util. Dispo Uti% Monté sur
udev                                                      10M     0   10M   0% /dev
run                                                       10M  228K  9,8M   3% /run
/dev/disk/by-uuid/f27936ad-8c28-41a7-bb7c-6c6c395012f4    25G   22G  1,5G  94% /
shm                                                      1,9G     0  1,9G   0% /dev/shm
/dev/sda2                                                101G   73G   28G  73% /media/sda2
/dev/sda3                                                 25G  172M   23G   1% /media/ctkarch
/dev/sdb1                                                 47G   47G  186M 100% /home
/dev/sdb4                                                 98G   56G   39G  60% /media/sdb4
/dev/loop0                                               146M   21M  126M  14% /var/lib/pacman

et de du :

Code : Tout sélectionner

5,8M    /bin
30M     /boot
0       /dev
9,1M    /etc
47G     /home
130M    /lib
2,7M    /lib32
4,0K    /lib64
16K     /lost+found
129G    /media
4,0K    /mnt
1,6G    /opt
0       /proc
1,6M    /root
228K    /run
11M     /sbin
16K     /srv
0       /sys
161M    /tmp
6,6G    /usr
4,9G    /var

ce qui confirme bien l'écart (bon, sans les 128 To de /proc/kcore, cool) :
df trouve 22G utilisés tandis que du me trouve toujours autour de 14 Go.

Note : je suis allé vérifier qu'il n'y avait rien de plus dans /media que les points de montage vus par df.

Code : Tout sélectionner

4,0K    /media/64A5-F009
4,0K    /media/CDRoot
4,0K    /media/CDRoot-1
20K     /media/ctkarch
4,0K    /media/iso
73G     /media/sda2
4,0K    /media/sda3
4,0K    /media/sdb1
56G     /media/sdb4

EDIT : et la sortie de du -xchd1 /, bien utile pour m'éviter la somme à la mano en effet :

Code : Tout sélectionner

2,7M    /lib32
0       /proc
16K     /lost+found
11M     /sbin
0       /dev
0       /home
0       /sys
8,0K    /.config
1,6M    /root
4,8G    /var
6,6G    /usr
40K     /media
130M    /lib
16K     /srv
1,6G    /opt
187M    /tmp
4,0K    /lib64
4,0K    /mnt
5,8M    /bin
30M     /boot
9,1M    /etc
0       /run
14G     /
14G     total

[tuxce]

Désolé, j'ai édité en même temps, tu peux poster la sortie de

Code : Tout sélectionner

du -xchd1 /

(ce que j'avais mis avant du -xchs /* fonctionne pas car /* intègre les /proc, /home etc.)

[Emericn6k]

Tu as édité à temps - voir mon post précédent

[benjarobin]

La sortie du "du" de Tuxce est un peu mieux, peux tu nous la donner, bien que je pense que l'on retrouve la même chose (Bon c'est bon, tu as édité)
Je trouve que 7 Go c'est beaucoup pour le système de fichier, car en effet le système de fichier prend de la place (Grosse table pour situé l'emplacement des fichiers), mais comme tu as du reiserfs c'est peut être normal, je ne sais pas je ne le connais que de nom

[tuxce]

hmmm, effectivement, c'est bizarre, par contre, je vois un .config dans la liste des répertoire du /, la sortie de ls -al / donnera peut être une explication.

[Emericn6k]

Oulà, effectivement, qu'est-ce qu'il fait là ce .config...

Code : Tout sélectionner

drwxr-xr-x  24 root root  4096 25 oct.  15:55 .
drwxr-xr-x  24 root root  4096 25 oct.  15:55 ..
drwxr-xr-x   2 root root  4096 28 oct.  09:45 bin
drwxr-xr-x   3 root root  4096  1 nov.  10:14 boot
drwxr-xr-x   2 root root  4096 20 déc.   2010 .config
drwxr-xr-x  15 root root  5420  2 nov.  09:03 dev
drwxr-xr-x  81 root root  4096  2 nov.  19:16 etc
drwxr-xr-x   8 root root   232  9 sept. 20:14 home
drwxr-xr-x  10 root root  4096 31 oct.  09:43 lib
drwxr-xr-x   2 root root  4096 25 oct.  10:44 lib32
drwxr-xr-x   2 root root  4096 25 oct.  06:58 lib64
drwx------   2 root root 16384 28 juin   2009 lost+found
drwxr-xr-x  11 root root  4096 26 oct.  18:54 media
drwxr-xr-x   2 root root  4096 10 oct.  01:25 mnt
drwxr-xr-x   4 root root  4096 30 oct.  22:13 opt
dr-xr-xr-x 174 root root     0  2 nov.  09:03 proc
drwxr-x---   8 root root  4096  2 nov.  18:53 root
drwxr-xr-x   6 root root   160  2 nov.  09:03 run
drwxr-xr-x   2 root root  4096 31 oct.  09:43 sbin
drwxr-xr-x   4 root root  4096 10 oct.  10:42 srv
drwxr-xr-x  13 root root     0  2 nov.  09:03 sys
drwxrwxrwt  21 root root  4096  2 nov.  19:50 tmp
drwxr-xr-x  11 root root  4096 12 sept. 09:38 usr
drwxr-xr-x  14 root root  4096 10 oct.  10:42 var

Le .config en question contient un Trolltech.conf qui sent le lancement d'appli Qt en root. Bizarre que ça n'ait pas atterri dans /root/.config.

[tuxce]

Tu es dans ce cas : http://www.cyberciti.biz/tips/freebsd-w ... utput.html ?
(intéressant d'ailleurs)

[Emericn6k]

@tuxce : je vais regarder, je n'étais pas encore tombé sur ce lien, merci! Par contre je donnerai sans doute la réponse demain, je pars


Sinon, oops, je dis n'importe quoi, ma partition c'est du ext4.
Reiserfs c'est mon /home... au temps pour moi.

J'en ai profité pour revérifier le fstab, google m'indiquant que ce genre de problème arrive parfois à cause de points de montage NFS.
Le dit fstab est le suivant :

Code : Tout sélectionner

# <file system>        <dir>         <type>    <options>          <dump> <pass>
devpts                /dev/pts      devpts    defaults            0      0
shm                   /dev/shm      tmpfs     nodev,nosuid        0      0

UUID=abfa85ab-7a94-4cfb-8159-69609c2f803a swap swap defaults 0 0
UUID=f27936ad-8c28-41a7-bb7c-6c6c395012f4 / ext4 defaults 0 1

UUID="e204d3b7-4890-4953-aabc-2586cbdc32bc" /media/sda2 reiserfs defaults 0 2
UUID="71e7ca3a-2154-4154-8dfb-ea2450eb137f" /media/ctkarch ext4 defaults 0 2
UUID="d9ba68db-1ab3-4ffe-8bb6-f43564e3c60e" /home reiserfs defaults 0 2
UUID="49058350-2b90-4c0c-b42c-e4b01b236a3b" /media/sdb4 ext2 defaults 0 2

[tuxce]

Pour le cas du lien que j'ai donné, il suffit de tester avec un système qui vient de démarrer.

[drs]

j'ai eu un probleme semblable il y a peu, les chances que ce soit la meme chose sont tres faibles mais sait-on jamais....
/ utilise a 100% alors qu'en faisant la somme, j'arrivais a peine a 1.3G. finalement, j'ai decouvert que j'avais des fichiers "invisibles" car ils se trouvaient sous un point de montage... erf...

[FoolEcho]

par contre, je vois un .config dans la liste des répertoire du /, la sortie de ls -al / donnera peut être une explication.

Rien de grave (même si perso, ça m'a toujours gavé depuis que je l'ai vu ) et rien à voir avec le problème. C'est simplement un bug de Kde (ou de Qt) qui traîne: https://bugs.kde.org/show_bug.cgi?id=249217. Il te suffit de te servir du mot de passe root, par exemple via le panneau de contrôle de Kde pour toute action qui nécessite les droits administrateur (date/heure, écran de démarrage, etc.) pour que ce .config apparaisse.
Vu le nombre de votes, on peut espérer que ça finisse par être corrigé (c'est peut-être à cause de Qt et le bug a été rapporté aussi, du coup).

[Emericn6k]

@drs : Ah bah oui. C'était ça. 8,1 Go cachés sous /home. J'ai dû utiliser mon système quelques temps avec une partition qui ne se montait pas, ou avec un fstab différent (pas de souvenirs, mais admettons ). Résolu donc ! Merci !



@tuxce : le cas décrit dans ton lien concerne plus les serveurs à mon avis, si j'ai bien compris un reboot règle le problème en question. En tous cas il n'y avait aucune chance que je trouve mes fichiers fantomes avec un lsof.

Merci pour vos réponses !