Justement, il faut le démonter pour voir ce qu’il y a dessous.
Oui ok j’ai bien compris mais, je préfère pas le faire tout de suite sinon je risque d’avoir quelques problèmes avec les personnes qui sont connectées dessus 
Mais permet moi d’avoir un doute par rapport à cette hypothèse de sous-volume dans home, comment est-ce possible ?
edit:–> home n’apparaît pas parace qu’il n’est pas sur la même partition.
Dans ce cas il y a un autre moyen : remonter la racine en bind sur un autre répertoire.
mkdir /tmp/bindroot
mount --bind / /tmp/bindroot
du -hxd1 /tmp/bindroot
umount /tmp/bindroot
rmdir /tmp/bindroot
1 J'aime
Si tu as un fichier présent dans /home, il n’est plus visible/accessible quand tu montes md3 dessus, mais il prend quand même sa place.
1 J'aime
Ok mais avec le resultat:
4,0K /lib64
4,0K /opt
8,0K /media
8,0K /mnt
12K /srv
16K /lost+found
200K /tmp
8,1M /root
8,9M /bin
18M /etc
22M /boot
23M /sbin
40M /lib
1,4G /usr
4,3G /var
5,8G /
On voit deja tres bien que ma partition / utilise que 5.8G alors que df -h me donne 15Go
Si je fais un mount --bind on va retrouver exactement ce que l’on contacte ici à savoir 5.8Go qui la taille reelle de ma partition /
Non, car la partition md3 ne sera pas montée sur /tmp/bindroot/home, donc le contenu de ta home dans cette arbo ne sera plus monté et le du indiquera la taille de son contenu.
Fais le, tu verras.
Non. C’est le total des fichiers visibles qui se trouvent dans le système de fichiers racine. Cela ne prend pas en compte les fichiers effacés mais encore ouverts ni les fichiers masqués sous un point de montage. Le montage avec --bind permet de voir les fichiers masqués sous un point de montage (mais pas les fichiers effacés ouverts).
OK tu me confirmes que c’est sans risque sur un serveur en prod ? 
Sans risque sauf si le point de montage temporaire /tmp/bindroot est déjà utilisé. Dans ce cas utilise un autre nom qui n’est par utilisé.
1 J'aime
Voici le resultat:
8,9M /tmp/bindroot/bin
8,1M /tmp/bindroot/root
4,0K /tmp/bindroot/opt
204K /tmp/bindroot/tmp
8,0K /tmp/bindroot/mnt
8,0K /tmp/bindroot/media
12K /tmp/bindroot/srv
64K /tmp/bindroot/run
40M /tmp/bindroot/lib
23M /tmp/bindroot/sbin
4,0K /tmp/bindroot/lib64
1,4G /tmp/bindroot/usr
4,3G /tmp/bindroot/var
4,0K /tmp/bindroot/proc
18M /tmp/bindroot/etc
16K /tmp/bindroot/dev
4,0K /tmp/bindroot/sys
22M /tmp/bindroot/boot
4,0K /tmp/bindroot/home
16K /tmp/bindroot/lost+found
5,8G /tmp/bindroot
et pour infos:
# df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/root 20G 16G 3,1G 83% /
devtmpfs 63G 0 63G 0% /dev
tmpfs 63G 0 63G 0% /dev/shm
tmpfs 63G 2,4G 61G 4% /run
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 63G 0 63G 0% /sys/fs/cgroup
/dev/md3 1,8T 252G 1,5T 15% /home
ftpback-rbx3-305.ovh.net:/export/ftpbackup/ns3616662.ip-51-255-69.eu 1000G 706G 295G 71% /mnt/FTPBackup
Reste donc la piste de fichiers supprimés encore ouverts ou orphelins.
Pour les fichiers orphelins, seule une vérification avec fsck lorsque la racine n’est pas montée peut les détecter et corriger.
Pour les fichiers supprimés ouverts, il faut redémarrer ou terminer les processus qui les gardent ouverts. Ces fichiers peuvent être identifiés avec de outils comme lsof (filtrer sur “deleted”) ou fuser.
1 J'aime
Merci pour ton excellent support.
Il s’agissait bien de fichiers encore ouverts “deleted”
la commande: lsof | grep deleted
m’a permis de voir que le processus apache2 avait besoin d’un redémarrage.
#df -h
/dev/root 20G 5,8G 13G 33% /
L’existence de fichiers supprimés encore ouverts n’est pas forcément une anomalie. C’est une technique classique utilisée pour que des fichiers temporaires ne soient pas accessibles par d’autre processus, et soient automatiquement effacés lors de leur fermeture.
S’ils sont dus au fonctionnement normal d’apache, ils reviendront.
Si ce volume constitue un problème pour l’occupation de la racine, alors il pourrait être opportun de les stocker dans un autre système de fichiers.
1 J'aime