「デバイスにスペースが残っていない」理由は他にもありますか？

Ubuntuサーバーシステムで、HDを外部USB 3.0ドライブにバックアップするために、Dirvishを使用しています。数日前までは、すべてが正常に機能していましたが、現在はすべてのバックアップが「デバイスに空き容量がありません（28）」および「ファイルシステムがいっぱい」で失敗します。残念ながら、それほど単純ではありません。デバイスには500 GBを超える空き容量があります。

詳細：

rsync_error：

rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename1>.eDJiD9": No space left on device (28)
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename2>.RHuUAJ": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename3>.9tVK8Z": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename4>.t3ARSV": No space left on device (28)
[... some more files ...]
rsync: connection unexpectedly closed (2712185 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

ログは、ヒットするまで通常どおりに見えます。

<SomeFilename1>
<SomeFilename2>
<SomeFilename3>
<SomeFilename4>
<PartOfAFilename>filesystem full
write error, filesystem probably full
broken pipe
RESULTS: warnings = 0, errors = 1

しかし、上記のように、デバイスには多くのスペースがあります。

df -h
/dev/sdg1       2.7T  2.0T  623G  77% /mnt/backupsys/shd

また、多くのiノードが残っています。

df -i
/dev/sdg1      183148544 2810146 180338398    2% /mnt/backupsys/shd

デバイスはrwとしてマウントされます。

mount
/dev/sdg1 on /mnt/backupsys/shd type ext3 (rw)

プロセスはルートとして実行されています。

私は何も変更していないと言っていましたが、それはまったく真実ではありません：バックアップしているドライブのaclをオンにしました：

/dev/md0 on /mnt/md0 type ext4 (rw,acl)

それが問題でしょうか？はいの場合、どのように？rootは引き続きファイルへのフルアクセスを持ちます。

編集：

一時ディレクトリを確認しました。

• / tmpには、空の.webminフォルダーのみが含まれています
• / var / tmpは空です

これらのディレクトリが存在するファイルシステムには、十分な空き領域とiノードがあります。

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       289G   55G  220G  20% /

df -i
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/sda1       19202048  167644  19034404    1% /

EDIT2：

ディレクトリは非常に大きいですが、2 GBを超えていません。バックアップが失敗するものは最大のものではなく、7530個のファイルが含まれています。

EDIT3：

この質問を投稿するときに、私が関連するとは思わなかった情報：

バックアップが失敗し始める前日、バックアップされたファイルシステムでACLをアクティブにしました。これにより、Dirvish（またはrsync）がすべてのファイルが変更されたと判断し、ハードリンクではなくコピーされるファイルのリストが非常に大きくなったと思われます。これは、一部のバッファが小さすぎることを意味する可能性があります。

今日、空のディスクへの完全バックアップは完璧に機能しました。次に増分バックアップを試みます。これは、ACLのアクティブ化が問題の原因であったかどうかを示します。

私の疑念（EDIT3を参照）は正しかったようです。ファイルシステムにaclサポートを追加すると、rsync / dirvishはすべてのファイルが変更されたと判断しました。そのため、増分バックアップを作成し、既存のファイルへのハードリンクを作成する代わりに、ハードディスクに十分なスペースがないため、もちろん失敗するフルバックアップを作成しようとしました。

したがって、エラーメッセージは実際には正しいものでした。

空のバックアップディスクで再度開始した後、増分バックアップは以前と同じように機能しました。

残りの2％のiノードを見ると、EXTファイルシステムが課しているルートリザーブについて考えるようになりました。これらを確認することをお勧めします。

1. 「ファイルシステムのルート用に予約されたスペース-なぜ？」
2. 「非OSディスクの「ファイルシステム予約ブロック」の合理的なサイズは？」

使用中のiノードの数を減らすことを期待して、古いバックアップのいくつかを.tar.gzで試します。

dummzeuchは彼の問題の解決策を見つけたようですが、実際には、ディスクに十分なinode /空き容量があり、特定のディレクトリを転送しようとするときに「デバイスに空き容量がありません」と表示されるケースがもう1つあります。

これは、ディレクトリインデックスが有効になっているext4ファイルシステムでフォーマットされたブロックデバイスでのハッシュ衝突が原因で発生します。特に、単一ディレクトリがその中に10万個以上のファイルをホストし、ファイル名が同じアルゴリズム（キャッシュファイル、md5sumファイル名など）から生成される場合）

解決策は、別のディレクトリインデックスアルゴリズムを試すことです。

tune2fs -E "hash_alg=tea" /dev/blockdev_name

または、そのブロックデバイスのディレクトリインデックス作成を完全に無効にする（パフォーマンスが低下する可能性があります）

tune2fs -O ^dir_index /dev/blockdev_name

別の解決策は、そのようなファイルでディレクトリを埋めているものを確認し、ソフトウェアを修正することです。

可能な解決策は、大量のファイルを含むフォルダーのコンテンツを複数の個別のサブフォルダーに分割することです。

問題の詳細な説明は、Axel Wagnerによってここに示されています。

http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

乾杯。

ディレクトリ自体には2GBのサイズ制限があります。つまり、ディレクトリサイズが2GBを超えるほど多くのファイルがある場合（ディレクトリ内のファイルのサイズではない）、問題が発生します。とは言っても、使用されているinodeは280万個だけなので、それは問題になりません。通常、1500万のiノードあたりで発生します。

だから、これはあまり助けにはならないかもしれません-しかし、バックアップデバイスでext4を試してみませんか？

sysctlでInotifyウォッチャーの制限を増やします。

fs.inotify.max_user_watches = 100000 

再起動するか、そのsysctl -wバージョンも実行します。

それは通常それを行います。カーネルで開かれているファイルが多すぎるため、エラーが完全に誤解を招きます。Dropboxはこの典型的な例です。

他にもいくつか確認することをお勧めします。

1. 一時ディレクトリがいっぱいになっていないかどうかを確認します。時には中間ストレージに使用され、簡単にいっぱいになります。
2. 削除されたファイルへの記述子をまだ保持しているプロセスがあるかどうかを確認します。dfは適切なサイズを報告するため、可能性は低くなりますが、それでも問題はありません。

私は自分の問題の解決策を探しているときにこのトピックを見つけました。

確かに、ENOSPCには少なくとも他の理由があります。ZFSファイルシステムからEXT4システムにコピーする際に、rsyncを使用します。

rsync: rsync_xal_set: lsetxattr(""/my/file/path"","example.xattr.attribute") failed: No space left on device (28)

この場合：

   ENOSPC - There is insufficient space remaining to store the extended attribute.

man 7 xattr 説明します：

   In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file's extended attributes
   must fit in a single filesystem block (1024, 2048 or 4096 bytes, depending on the block size specified when the filesystem was created).

私の場合、ファイルシステム全体を再フォーマットする必要があります。:-(