Solution 1 :
Regarder les 2% d'inodes restants m'a fait penser aux réserves racine qu'impose le système de fichiers EXT. Vous voudrez peut-être les consulter :
- "Espace réservé pour root sur un système de fichiers - pourquoi ?"
- "Taille raisonnable pour les "blocs réservés au système de fichiers" pour les disques non OS ?"
J'essaierais de .tar.gz certaines des anciennes sauvegardes en espérant que cela réduirait le nombre d'inodes utilisés.
Solution 2 :
Ma suspicion (voir EDIT3) était apparemment juste :l'ajout du support acl au système de fichiers a fait penser à rsync/dirvish que tous les fichiers avaient changé. Ainsi, au lieu de faire une sauvegarde incrémentielle et de simplement créer des liens physiques vers les fichiers déjà existants, il a essayé de créer une sauvegarde complète qui a bien sûr échoué car le disque dur n'avait pas assez d'espace pour cela.
Le message d'erreur était donc correct.
Après avoir recommencé avec un disque de sauvegarde vide, les sauvegardes incrémentielles ont fonctionné comme avant.
Solution 3 :
Je vois que dummzeuch trouve une solution à son problème, mais il y a en fait un autre cas que j'ai trouvé où le disque peut avoir suffisamment d'inodes/d'espace libre et afficher toujours "pas d'espace restant sur le périphérique" lors de la tentative de transfert de certains répertoires.
Cela est dû à des collisions de hachage sur des périphériques de bloc formatés avec le système de fichiers ext4 où l'indexation de répertoire est également activée, en particulier lorsqu'un seul répertoire héberge plus de 100 000 fichiers et que le nom des fichiers est généré à partir du même algorithme (fichiers cache, noms de fichiers md5sum, etc. .)
La solution consiste à essayer avec un autre algorithme d'indexation de répertoire :
tune2fs -E "hash_alg=tea" /dev/blockdev_name
ou pour désactiver complètement l'indexation des répertoires pour ce périphérique de bloc (peut nuire aux performances)
tune2fs -O ^dir_index /dev/blockdev_name
Une autre solution consiste à voir ce qui remplit le répertoire avec de tels fichiers et à corriger le logiciel.
La solution possible consiste à diviser le contenu du dossier contenant un énorme volume de fichiers en plusieurs sous-dossiers distincts.
La description complète du problème est présentée par Axel Wagner ici
http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html
Bravo.