petit mystère de taille de répertoires sur mon disque dur

[Glenic1]

Bonjour,
Mon vieil ordi Acer 7630 (sous LinuxMint 19.3) est équipé d'un disque dur de 500 Go.
C'est une taille respectable qui permet d'ajouter des fichiers et des répertoires sans se préoccuper de la taille-limite du disque dur.
En particulier, ma partition de données ("home") mesure 315 Go.
L'utilitaire "disques" de LinuxMint me renseigne sur le % d'occupation de la partition /home.
Il m'indique que ce /home n'est occupé qu'à 62 %
Il y a donc 195 Go occupés et 120 Go libres.

Mais je vais bientôt changer d'ordinateur. Le nouveau est équipé d'un SSD de 240 Go "seulement"
Il faut donc vérifier à l'avance si toutes les données de l'ordi actuel vont bien rentrer sur le nouveau.
Je suspecte un problème car s'il faut conserver en gros 200 Go de /home, il n'y aura pas beaucoup de place pour la partition /system et aussi une petite partition LUKS qui abrite mes données perso.

Le réflexe est donc d'aller voir quels sont les répertoires de /home qui occupent le plus gros volume.
Avec un peu de chance, certaines données volumineuses ne sont pas très utiles ou obsolètes et elles n'auront pas besoin d'aller sur le nouveau disque dur.
Mon explorateur (Thunar, chargé d'office sur LinuxMint) ne permet pas d'afficher la taille des sous-répertoires directs de /home
Dommage !
Un autre explorateur disponible sur mon ordi PCManFM ne permet pas non plus d'afficher la taille de chacun des sou-répertoires directs.

Heureusement une recherche rapide m'indique la commande

Code : Tout sélectionner

ncdu

qui donne le résultat.
Allons-y pour un peu de ligne de commande, pas trop difficile.
Mais le résultat est tout à fait paradoxal : le volume total des sous-répertoires directs fait à peine 30 Go alors que l'utilitaire "disques" indique une taille globale de 195 Go.
Il y a donc 160 Go "dans la nature" quelque part dans le répertoire /home

Il y a quelque part des répertoires "super cachés" mais où ?
Je soupçonne en particulier timeshift. Mais il y en a sans doute d'autres.
Comment les atteindre ? Peut-on s'en passer ?

[patoo45]

en mode ligne de commande dans le répertoire /home/utilisateur ou utilisateur est le nom de "login" (connexion)
puis

Code : Tout sélectionner

ls -al

"ls" est la commande pour lister les rep et fic sous le répertoire courant
-a permet de voir les rep et fic cachés (qui commence par un "point"
-l permet d'avoir toutes les informations des rep et fic: droits d'accès, taille, etc...
Permet de voir tous les répertoires/fichiers cachés donc je suppose, ceux de firefox et ceux de thunderbird

[maxoxo]

Salut,

Il y a plusieurs méthodes pour atteindre le but recherché. Je ne suis pas un grand fan de ncdu (qui n'est qu'un frontend en ncurses pour la commande du).

1. La commande ls

La méthode indiquée par patoo45 est simple et efficace si l'on cherche dans un répertoire précis et avec un contenu limité. Elle peut devenir difficile à interpréter ou à manier si tu la lances sur un répertoire de trop haut niveau car elle te listera tout y compris les fichiers qui font quelques octets.

On peut l'enrichir un peu, mais je dirais que ls doit être prise pour ce qu'elle est : une commande ayant vocation à lister le contenu d'un répertoire.

Tu peux essayer

Code : Tout sélectionner

ls -l -a -h -S

-a permet de voir les rep et fic cachés (qui commence par un "point"
-l permet d'avoir toutes les informations des rep et fic: droits d'accès, taille, etc..

Par rapport à ce qu'indique patoo45, j'ajoute donc deux paramètres qui peuvent aider :
- h pour "human-readable" qui indique que l'on veut que les formats soient indiqués dans un format lisible par un humain. Ainsi plutôt qu'une taille en octets, on aura des suffixes K, M, G (kilo, méga, giga) plutôt qu'une taille en octets qui va vite devenir difficile à lire.
- S qui est un raccourci pour l'argument --sort=size visant à classer les fichiers par taille décroissante. Les fichiers les plus volumineux se retrouveront en haut de la liste.

On peut ajouter un -R qui veut dire "récursif" ça listera tous les fichiers et tous les sous-dossiers, mais ça risque de vite devenir ingérable

2. La commande du

On peut effectivement utiliser du qui est fait pour afficher l'espace utilisé par les fichiers et les répertoires. En couplant du avec d'autres commandes shell plus classiques qu'on cumulera avec un pipe

Code : Tout sélectionner

|

on peut obtenir une sortie efficace pour atteindre l'objectif recherché.

Tu peux ainsi tenter

Code : Tout sélectionner

du -ahx . | sort -rh | head -10

Je décompose :
-[*] du -ahx . : lancer la commande du dans le répertoire courant indiqué par . / compter à la fois et les fichiers et les répertoires (-a) / afficher les tailles dans un format lisible par un humain (-h) / ignorer les fichiers et répertoires sur des systèmes différents comme par exemple un lecteur réseau monté en NFS (-x)
-[*] sort -rh : classer les résultats par taille décroissante en comparant les formats lisibles par un humain (-h) et en inversant le résultat (-r) ;
-[*] head -10 : n'afficher que les 10 premiers résultats, tu peux changer la valeur comme tu le souhaites.

Dans cette config, tu verras s'afficher en premier les répertoires qui pèsent le plus lourd, puis en dessous le détail des fichiers pesant le plus lourd au sein de ces répertoires.

3. Comme un pro : avec la commande find

Je ne vais pas pouvoir détailler ça aujourd'hui, mais je donne la commande à toutes fins utiles :

Code : Tout sélectionner

find . -xdev -type f -size +100M -print

Cette commande va permettre de lister tous les fichiers qui font plus de 100 Mo. Tu peux moduler la taille recherchée comme tu le souhaites avec l'argument size. Dans mon exemple c'est 100M pour + de 100 Mo mais tu peux très bien faire "size +500M" pour indiquer que tu veux ceux qui pèsent + de 500 Mo. Attention à bien indiquer + sinon ça cherchera les fichiers qui font précisément la taille indiquée.

Cette commande est récursive donc elle fouille y compris les sous-dossiers.

Si tu la lances sur / tu fouilleras l'intégralité du système. Le cas échéant, il faut la lancer en root pour contourner les problèmes de droits de lecture.

[Glenic1]

Salut Patoo et Maxoxo,
Merci pour ces commandes qui enrichissent mon vocabulaire "lignes de commandes".
J'ai essayé chacune d'entre elles.

- la commande

Code : Tout sélectionner

ncdu

fonctionne pas mal.

- la commande

Code : Tout sélectionner

ls

est utile mais pas dans mon cas car je voulais surtout les tailles de répertoires

- la commande

Code : Tout sélectionner

du -ahx . | sort -rh | head -10

est la meilleure pour cette recherche de tailles

- la commande

Code : Tout sélectionner

find . -xdev -type f -size +100M -print

est subtile mais détecte les volumes de fichiers alors que c'est plutôt la taille des répertoires que je cherchais.

En définitive, j'ai résolu le mystère :
J'avais recherché la taille du seul répertoire personnel alors qu'il y avait 2 autres répertoires très lourds dans le /home
En fouillant dans le vrai /home, j'ai découvert facilement les 170 Go et quelques qui me manquaient.
- une pseudo-sauvegarde d'un ensemble de répertoires anciens rapatriés en vrac depuis d'autres ordis plus anciens que mon Acer actuel (113 Go quand même)
- et le fameux Timeshift qui pèse 60 Go à lui tout seul pour seulement 2 instantanés, soit 30 Go par instantané.
Rien à dire sur le fond car il est correctement paramétré à ma sauce : seulement un instantané par mois avec suppression automatique du n - 2 à chaque fois. Donc la taille du répertoire .timeshift restera aux alentours de 60 Go. Sur le nouvel ordi, je le paramétrerai encore plus sévèrement : sauvegarde d'un seul instantané avec suppression automatique de chaque n - 1.
Et surtout : stockage de l'instantané sur la partition "données" et pas "système". J'avais eu une fois un blocage de l'ordi à cause du timeshift qui avait saturé la partition "système". J'avais dû ré-installer l'OS complètement !

[maxoxo]

et le fameux Timeshift qui pèse 60 Go à lui tout seul pour seulement 2 instantanés, soit 30 Go par instantané.

Visiblement cet outil pose plus de problèmes qu'il n'apporte de solutions. Je ne sais plus combien de personnes j'ai dépanner pour un problème avec Timeshift.
C'est bien pour ça que je préfère les snapshots Btrfs à tout autre système, au moins avec la déduplication ils ne consomment pas le double d'espace !

Et surtout : stockage de l'instantané sur la partition "données" et pas "système". J'avais eu une fois un blocage de l'ordi à cause du timeshift qui avait saturé la partition "système". J'avais dû ré-installer l'OS complètement !

Je m'en souviens bien !

[Glenic1]

Hello Maxoxo,
BTRFS est un bien un genre de fichiers, comme par exemple ext4 ?
Ce n'est pas une appli spéciale pour faire des instantanés (=snapshots) ?
On peut choisir BTRFS au moment de l'installation de LinuxMint, au moins pour la partition système, plutôt qu'un autre genre comme ext4 par exemple ?

[maxoxo]

Hello Maxoxo,
BTRFS est un bien un genre de fichiers, comme par exemple ext4 ?
Ce n'est pas une appli spéciale pour faire des instantanés (=snapshots) ?
On peut choisir BTRFS au moment de l'installation de LinuxMint, au moins pour la partition système, plutôt qu'un autre genre comme ext4 par exemple ?

Hello,

Exactement, Btrfs est un bien un système de fichiers à part entière au même titre que le bon vieux ext4. Pour l'utiliser il faut donc formater les partitions au moment du choix de la distribution. La plupart des distributions le proposent désormais depuis des années et je crois que Fedora et Ubuntu l'utilisent même comme système de fichiers par défaut dans leurs dernières versions.

Il existe depuis 2009, mais il a longtemps été considéré comme expérimental. Personnellement je l'utilise comme système de fichiers depuis 2011 sur mon Archlinux. Je ne suis jamais revenu en arrière et il est en évolution constante. Aujourd'hui il est considéré comme stable. Honnêtement, dès 2011, j'avais senti un gros boost de performances sur mon système par rapport à ext4. Cela s'explique aussi par le fait que Btrfs a été conçu pour être optimisé sur les SSD.

L'article Wikipédia est assez clair sur les avantages de Btrfs : https://fr.wikipedia.org/wiki/Btrfs

Un autre article français qui présente très bien les concepts de Btrfs est dispo ici : https://sebsauvage.net/wiki/doku.php?id ... y-on-write

Je te laisse découvrir, mais les principales forces sont pour moi les sous-volumes et les snapshots (instantanés), le Copy-on-Write et la compression. Avec du Btrfs bien géré, on peut éviter beaucoup de problèmes et limiter drastiquement les risques de perte de données. C'est d'ailleurs le système utilisé par défaut par de nombreux NAS pour faire du RAID.

[Glenic1]

Note pour les débutants (comme moi) :

NAS = Network Attached Storage = unité de stockage réseau
Peut-on dire qu'un disque dur externe est le degré zéro du NAS ? (juste pour se faire une idée)

RAID = Redundant Array of Independent Disks = regroupement redondant de disques indépendants = un ensemble de mesures permettant de répartir le stockage entre plusieurs disques durs

[Stéphane Ascoët]

NAS = Network Attached Storage = unité de stockage réseau
Peut-on dire qu'un disque dur externe est le degré zéro du NAS ? (juste pour se faire une idée)

C'est plutôt le terme anglais à la mode qui a remplacé le bien plus explicite "serveur de fichiers" en bon français... c'est quand même bien différent d'un stockage passif. Mais beaucoup confondent les deux, on a parfois des utilisateurs qui nous demandent de l'aide pour leur "Apple capsule" en croyant que c'est un simple disque dur, alors que c'est en fait un Nas domestique(interdit à l'université). Sur nos serveurs l'usage de LVM est généralisé, notamment pour éviter facilement le problème de saturation que tu as eu. Et moi même j'en suis utilisateur sur ma machine professionnelle(avec de l'XFS dessus). Par contre je n'ai pas essayé BT machin car il m'a toujours paru surdimensionné pour mes besoins et mes très vieux ordinateurs, et puis quel nom imprononçable et impossible à retenir franchement...