解決策 1:
残りの 2% の inode を見て、EXT ファイルシステムが強制するルート予約について考えさせられました。これらをチェックしてみてください:
<オール>使用中の inode の数を減らすことを期待して、古いバックアップのいくつかを .tar.gz しようとします。
解決策 2:
私の疑い (EDIT3 を参照) は明らかに正しかったようです。ファイル システムに acl サポートを追加すると、rsync/dirvish はすべてのファイルが変更されたと見なされます。そのため、増分バックアップを作成して既存のファイルへのハード リンクを作成する代わりに、完全バックアップを作成しようとしましたが、ハードディスクに十分なスペースがなかったため、もちろん失敗しました。
したがって、エラー メッセージは実際には正しかったのです。
空のバックアップ ディスクで再開した後、増分バックアップは以前と同じように機能しました。
解決策 3:
dummzeuch が彼の問題の解決策を見つけたようですが、実際には、ディスクに十分な inode/空き容量があり、特定のディレクトリを転送しようとしているときに「デバイスに空き容量がありません」と表示されるケースがもう 1 つあります。
これは、ext4 ファイル システムでフォーマットされたブロック デバイスでのハッシュ衝突が原因で発生します。この場合、特に単一のディレクトリが 10 万を超えるファイルをホストし、ファイルの名前が同じアルゴリズム (キャッシュ ファイル、md5sum ファイル名など) から生成される場合に、ディレクトリのインデックス作成が有効になっています。 .)
解決策は、別のディレクトリ インデックス作成アルゴリズムを試すことです:
tune2fs -E "hash_alg=tea" /dev/blockdev_name
または、そのブロック デバイスのディレクトリ インデックス作成を完全に無効にする (パフォーマンスが低下する可能性があります)
tune2fs -O ^dir_index /dev/blockdev_name
もう 1 つの解決策は、そのようなファイルでディレクトリがいっぱいになっている原因を確認し、ソフトウェアを修正することです。
考えられる解決策は、膨大な量のファイルが含まれるフォルダーのコンテンツを複数の個別のサブフォルダーに分割することです。
この問題の完全な説明は、アクセル ワグナーがここに示しています
http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html
乾杯。