Partition racine pleine

Support Debian
#1

Bonjour à tous,

Ma partition / est pleine et je ne comprends pas pourquoi. C’est un PC sous Lenny avec le noyau 2.6.32-5-amd64. J’ai essayé de voir où se trouvaient les fichiers prenant de la place avec Baobab et j’ai réussi à supprimer certains fichiers log, la corbeille, les fichiers temporaires. Baobab m’indique maintenant 10Go d’occupé sur les 15 Go de ma partition :041 , sauf que dans la console, la commande df -h me sort Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/sda1 14G 14G 27M 100% / tmpfs 1007M 0 1007M 0% /lib/init/rw udev 1003M 676K 1002M 1% /dev tmpfs 1007M 0 1007M 0% /dev/shm /dev/sda8 5,6G 4,0K 5,6G 1% /fat32 /dev/sda6 28G 1,9G 25G 8% /home /dev/sda7 14G 914M 13G 7% /opt /dev/sda2 9,2G 150M 8,6G 2% /test /dev/sdb2 15G 189M 14G 2% /svn /dev/sdb1 39G 3,8G 33G 11% /save /dev/sdb3 21G 173M 20G 1% /divers overflow 1,0M 72K 952K 8% /tmp :118
Que peut expliquer cette disparité entre l’outil graphique et la console ?
Comment rechercher avec la console les fichiers consommateurs d’espaces ?

Merci pour vos conseils.

#2

Les fichiers sont encore ouverts et donc ne sont toujours pas effacés concrètement du disque (c’est une hypothèse).

#3

Salut,

Un # du -h sur /tmp et /var ? révèle parfois des surprises :slightly_smiling:

#4

Merci à vous deux,
J’ai redémarré le système pour vérifier l’hypothèse de fran.b. Hélas, aucun résultat.

[quote=“ggoodluck47”]Salut,
Un # du -h sur /tmp et /var ? révèle parfois des surprises :slightly_smiling:[/quote]

# du -h /tmp 4,0K /tmp/.ICE-unix 4,0K /tmp/keyring-JZPGQg 4,0K /tmp/seahorse-XAQNwG 12K /tmp/libgksu-VXryQH 8,0K /tmp/orbit-jp 4,0K /tmp/.X11-unix 8,0K /tmp/gconfd-root/lock 12K /tmp/gconfd-root 4,0K /tmp/virtual-jp.D3Fzrn 4,0K /tmp/hsperfdata_root 36K /tmp/hsperfdata_tomcat55 8,0K /tmp/orbit-root 8,0K /tmp/gconfd-jp/lock 12K /tmp/gconfd-jp 124K /tmp
Je résume la commande sur /var car celle-ci est très longue mais se termine par la ligne

# du -h /var 822M /var
ce qui n’explique pas les 5 Go de différence.

#5

Bon, alors fais simplement ceci

mkdir /home/tempo

mount /dev/sda1 /home/tempo

du -sh /home/tempo

(Là tu vas voir 14G)

puis tu fais

du -sh /home/tempo/lib/init/rw du -sh /home/tempo/dev du -sh /home/tempo/dev/shm du -sh /home/tempo/fat32 du -sh /home/tempo/home du -sh /home/tempo/opt du -sh /home/tempo/test du -sh /home/tempo/svn du -sh /home/tempo/save du -sh /home/tempo/divers du -sh /home/tempo/tmp

ce qui te permettra de voir où est le pbm. (Je parie sur /home/tempo/tmp).
Tu fais un

rm -Rf /home/tempo/tmp
(adapte)
umount /home/tempo
rmdir /home/tempo

et le pbm sera réglé.

#6

Merci fran.b de te pencher sur mon problème.
J’ai donc fait ce que tu m’as demandé. Je te passe toutes les commandes # du -sh /home/tempo/xxxx
Elle me donne toutes 4k, la taille du répertoire, ce qui est normal. Toutes, sauf … perdu ! ce n’est pas ‘tmp’ mais ‘save’ (9 Go) qui est une partition de sauvegarde automatique de mes fichiers et qui se trouve sur un deuxième disque ! Comment se fait-il qu’il compte dans la taille de la partition / alors qu’il se trouve sur une partition d’un autre disque ? Avant de l’effacer, j’aimerais comprendre.

#7

Salut,

Parce que c’est la taille de la RACINE pas celle d’un disque !

Tant que nous continuerons à parler comme à Redmond de disque pour désigner les partitions nous aurons ce genre d’incompréhension :slightly_smiling:

#8

Simple, tu as fait une sauvegarde alors que le disque n’était pas monté. Et bing, 9G invisible dès que tu montes la /save normalement.

#9

Hola ! :stuck_out_tongue:
J’ai besoin d’une explication de texte, là.
Je veux bien croire ce que vous me dites, mais par exemple, quelle est la différence entre ma partition ‘save’ et ma partition ‘svn’. Les deux sont montées dans le fstab que je vous recopie ci-dessous et pourtant save ‘prend’ 9Go dans la racine et svn seulement 4ko. Sur ces deux partitions, les écritures se font sur l’une comme sur l’autre lorsque mon environnement Gnome est démarré (et donc les partitions montées).

[code]# /etc/fstab: static file system information.

proc /proc proc defaults 0 0

/dev/hda1 / ext3 errors=remount-ro 0 1

UUID=2ca9485f-9082-4b6b-84ce-408c7bb7a489 / ext3 errors=remount-ro 0 1

/dev/hda8 /fat32 vfat utf8 0 0

UUID=E2AA-CF01 /fat32 vfat utf8 0 0

/dev/hda6 /home ext3 defaults 0 2

UUID=9e4cf249-639c-4df4-bc6c-b97e0ae1f5b1 /home ext3 defaults 0 2

/dev/hda7 /opt ext3 defaults 0 2

UUID=e6c06331-c111-4313-8ce9-a5268ea92ac2 /opt ext3 defaults 0 2

/dev/hda2 /test ext3 defaults 0 2

UUID=5fcf5cc7-2dbf-4077-98c6-d27e9bfb1450 /test ext3 defaults 0 2

/dev/hda5 none swap sw 0 0

UUID=7e6171fa-1425-48dd-89e8-b3960b3b2fc4 none swap sw 0 0
/dev/sdb2 /svn ext3 defaults 0 0
#UUID=4b6e87f0-2f07-4625-9bc2-f1013a31dd8b /svn ext3 defaults 0 0
/dev/sdb1 /save ext3 defaults 0 0
UUID=3d67c8e2-71ba-4d8d-9f30-7786cb7bbf15 /save ext3 defaults 0 0
/dev/sdb3 /divers ext3 defaults 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
#/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0

Montage Perso pour le FTP

/var/www /var/lib/ftp/jp/www none bind 0 0
[/code]

#10

Ce que tu as dans /home/tempo est la partition /dev/sda1 sans rien de monté dessus. Les 9G sous save dans cette partition sont des données écrites lorsque /save n’avait pas été montée.

/home/tempo/svn ne contient que la place nécessaire à un répertoire soit 4K

#11

Merci beaucoup pour ton aide, je me coucherais moins bête ce soir.