J’ai voulu recopier mes sauvegardes sur mon disque Linux juste parce qu’il restait 200 Go libres : chaque fichier a été refusé sans la moindre explication

Un disque annoncé à moitié vide qui refuse pourtant le moindre fichier : voilà le genre de contradiction qui rend fou n’importe quel utilisateur Linux un dimanche soir. Et la réponse ne tient presque jamais à la taille du disque, mais à deux mécanismes que Windows et macOS cachent soigneusement : le système de fichiers cible et le nombre d’inodes disponibles.

Le coupable numéro un : la limite de 4 Go du FAT32

Avant même de sortir le terminal, il faut regarder de quoi est formaté ce fameux disque. Si c’est du FAT32, hérité d’un vieux disque externe ou d’une clé jamais reformatée, chaque fichier de sauvegarde dépassant 4 Go sera automatiquement rejeté, peu importe l’espace libre restant. La taille maximale d’un seul fichier formaté en FAT32 est de 4 Go, et vous pouvez recevoir un message d’erreur indiquant que le fichier est trop grand pour le système de fichiers de destination dès que vous dépassez ce seuil. Une archive de sauvegarde compressée, une image disque ISO ou un fichier de VM font très facilement ce poids-là.

Le pire, c’est que le message d’erreur est souvent générique sous Linux, du type « fichier trop volumineux » sans plus de contexte, ce qui laisse penser à un bug plutôt qu’à une limite technique vieille de plus de trente ans. La cause est souvent simple : le support est formaté en FAT32, qui limite la taille du fichier à 4 Go, même quand il reste largement de la place. La solution ne demande pourtant aucune bidouille compliquée : reformater en exFAT réglera le problème sans perdre la compatibilité multiplateforme, puisque ce format est compatible avec Windows, macOS, Linux, téléviseurs et consoles modernes, sans risque d’erreur avec les fichiers supérieurs à 4 Go. Sur un système strictement Linux, ext4 reste évidemment le choix le plus robuste, avec une limite de taille de fichier qui se compte en téraoctets.

Le piège invisible : plus d’inodes, même avec des giga-octets libres

Si le disque tourne déjà en ext4, le problème est ailleurs, et il est nettement plus vicieux. Sous Linux, chaque fichier ne consomme pas seulement de l’espace disque, il consomme aussi un inode, cette petite structure qui stocke les métadonnées (droits, dates, emplacement des blocs). Chaque fichier occupe un inode, une structure de métadonnées qui stocke les permissions, les timestamps et les pointeurs vers les blocs de données, et le nombre total d’inodes est fixé à la création du filesystem sur ext4. Ce nombre est décidé une bonne fois pour toutes, souvent à la création de la partition, en fonction de sa taille moyenne estimée.

Le souci, c’est qu’une sauvegarde composée de dizaines de milliers de petits fichiers (photos, mails exportés, projets de code avec leurs dépendances) peut épuiser ce quota d’inodes bien avant de saturer l’espace physique. La réponse se situe au niveau des inodes : sur un même volume, le nombre de fichiers est limité, et on peut saturer un volume avec un très grand nombre de petits fichiers sans pour autant saturer l’espace disque en lui-même. Résultat : df -h affiche fièrement vos 200 Go libres, pendant que chaque tentative de copie se heurte à un mur silencieux. Le seul moyen de vérifier ça proprement, c’est de lancer df -i à la place de df -h. Une écriture qui échoue alors que df -h affiche des gigaoctets libres ne peut pas s’expliquer autrement ; il suffit de vérifier si df -h montre de la place disponible mais qu’une écriture retourne No space left on device. J’ai vu ce cas sur un vieux NAS familial rempli à ras bord de miniatures de photos : des centaines de milliers de fichiers minuscules avaient grillé les inodes sans jamais approcher les limites de stockage.

D’autres suspects moins connus mais tout aussi fourbes

Il existe une troisième explication, plus discrète encore : les blocs réservés au super-utilisateur. Sur ext4, une portion du disque est mise de côté par défaut pour garantir que le système continue de fonctionner même quand l’espace se raréfie. Le fait de réserver une certaine quantité de blocs du système de fichier au super-utilisateur a un objectif précis, et par défaut, 5% des blocs du système sont réservés. Les autres applications fonctionnant en mode non-privilégié ne pourront plus écrire sur le disque une fois cette limite atteinte, sauvegardant ainsi l’espace de réserve. Sur un disque de plusieurs téraoctets, ces 5 % représentent facilement plusieurs dizaines de gigaoctets invisibles dans les gestionnaires de fichiers classiques.

Dernier piège, plus rare mais redoutable : des fichiers supprimés qui restent malgré tout ouverts par un processus en arrière-plan. Tant qu’il existe une référence active à un inode, les blocs occupés par le fichier sont considérés comme utilisés, donc tant qu’un fichier reste ouvert par un processus en cours, l’espace sera toujours utilisé sur le système de fichiers. Un service planté ou un journal qui tourne en boucle peut ainsi grignoter de l’espace fantôme, invisible à l’œil nu mais bien réel pour le noyau.

Comment sortir de l’impasse sans tout reformater

Le réflexe à avoir avant de paniquer ou de reformater bêtement le disque, c’est de croiser deux commandes toutes simples : df -h pour l’espace physique, et df -i pour les inodes. Si la colonne « IUse% » affiche 100 %, la cause est identifiée immédiatement. Pour repérer les dossiers qui grouillent de petits fichiers inutiles, un find /chemin -type f | wc -l répertoire par répertoire fait gagner un temps fou, sachant qu’il n’existe pas d’équivalent de du pour compter les inodes, il faut dénombrer les fichiers répertoire par répertoire. Et si le disque de sauvegarde traîne depuis des années en FAT32 hérité d’un vieux boîtier externe, un reformatage en exFAT ou en ext4 réglera définitivement le problème, avec l’avantage que la seule solution durable reste de changer le système de fichiers vers un format compatible, capable d’encaisser aussi bien les gros fichiers que les millions de petits.

Sources : support-fr.sandisk.com | support-fr.wd.com