Řešení 1:
Pohled na 2 % zbývajících inodů mě přiměl přemýšlet o kořenových rezervách, které souborový systém EXT ukládá. Můžete se podívat na tyto:
- "Vyhrazené místo pro root na souborovém systému - proč?"
- „Přiměřená velikost pro „bloky vyhrazené systémem souborů“ pro disky bez OS?“
Zkusil bych .tar.gz některé ze starších záloh v naději, že to sníží počet používaných inodů.
Řešení 2:
Moje podezření (viz EDIT3) bylo zřejmě správné:Přidání podpory acl do systému souborů způsobilo, že rsync/dirvish si myslel, že se všechny soubory změnily. Takže místo vytvoření přírůstkové zálohy a pouhého vytvoření pevných odkazů na již existující soubory se pokusilo vytvořit plnou zálohu, což samozřejmě selhalo, protože na pevném disku na to nebyl dostatek místa.
Takže chybová zpráva byla ve skutečnosti správná.
Po opětovném spuštění s prázdným zálohovacím diskem fungovaly přírůstkové zálohy jako předtím.
Řešení 3:
Vidím, že dummzeuch našel řešení svého problému, ale ve skutečnosti jsem našel ještě jeden případ, kdy disk může mít dostatek inodů/volného místa a při pokusu o přenos určitých adresářů stále zobrazuje „na zařízení nezbývá žádné místo“.
To je způsobeno kolizemi hash na blokových zařízeních naformátovaných souborovým systémem ext4, kde je povoleno také indexování adresářů, zejména tam, kde jeden adresář obsahuje více než 100 000 souborů a názvy souborů jsou generovány stejným algoritmem (soubory mezipaměti, názvy souborů md5sum atd. .)
Řešením je zkusit jiný algoritmus indexování adresářů:
tune2fs -E "hash_alg=tea" /dev/blockdev_name
nebo úplně zakázat indexování adresářů pro toto blokové zařízení (může snížit výkon)
tune2fs -O ^dir_index /dev/blockdev_name
Dalším řešením je zjistit, co zaplňuje adresář takovými soubory, a opravit software.
Možným řešením je rozdělení obsahu složky s velkým objemem souborů v ní do více samostatných podsložek.
Úplný popis problému uvádí Axel Wagner zde
http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html
Na zdraví.