Lösung 1:
Als ich mir die 2 % der verbleibenden Inodes ansah, dachte ich über die Root-Reserven nach, die das EXT-Dateisystem auferlegt. Vielleicht möchten Sie sich diese ansehen:
- "Reservierter Speicherplatz für root auf einem Dateisystem - warum?"
- "Angemessene Größe für "vom Dateisystem reservierte Blöcke" für Nicht-Betriebssystemfestplatten?"
Ich würde versuchen, einige der älteren Backups mit .tar.gz zu versehen, in der Hoffnung, dass dies die Anzahl der verwendeten Inodes reduzieren würde.
Lösung 2:
Mein Verdacht (siehe EDIT3) war anscheinend richtig:Das Hinzufügen von ACL-Unterstützung zum Dateisystem ließ rsync/dirvish glauben, dass sich alle Dateien geändert hätten. Anstatt also ein inkrementelles Backup zu erstellen und nur harte Links zu den bereits vorhandenen Dateien zu erstellen, versuchte es, ein vollständiges Backup zu erstellen, was natürlich fehlschlug, weil die Festplatte dafür nicht genug Platz hatte.
Die Fehlermeldung war also eigentlich richtig.
Nach erneutem Start mit leerem Backup-Datenträger funktionierten die inkrementellen Backups wie zuvor.
Lösung 3:
Ich sehe, dass Dummzeuch eine Lösung für sein Problem findet, aber es gibt tatsächlich einen weiteren Fall, den ich gefunden habe, wo die Festplatte genug Inodes/freien Speicherplatz haben kann und immer noch "kein Speicherplatz auf dem Gerät übrig" anzeigt, während versucht wird, bestimmte Verzeichnisse zu übertragen.
Dies wird durch Hash-Kollisionen auf Blockgeräten verursacht, die mit dem ext4-Dateisystem formatiert sind, wo auch die Verzeichnisindizierung aktiviert ist, insbesondere wenn ein einzelnes Verzeichnis mehr als 100.000 Dateien enthält und die Namen der Dateien aus demselben Algorithmus generiert werden (Cache-Dateien, md5sum-Dateinamen usw .)
Die Lösung besteht darin, es mit einem anderen Verzeichnisindizierungsalgorithmus zu versuchen:
tune2fs -E "hash_alg=tea" /dev/blockdev_name
oder um die Verzeichnisindizierung für dieses Blockgerät vollständig zu deaktivieren (kann die Leistung beeinträchtigen)
tune2fs -O ^dir_index /dev/blockdev_name
Eine andere Lösung besteht darin, zu sehen, was das Verzeichnis mit solchen Dateien füllt, und die Software zu reparieren.
Mögliche Lösung ist das Aufteilen des Inhalts eines Ordners mit einer großen Menge an Dateien in mehrere separate Unterordner.
Eine vollständige Beschreibung des Problems wird von Axel Wagner hier präsentiert
http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html
Prost.