web-dev-qa-db-ja.com

「デバイスに空き容量がない」理由は他にありますか？

私は、HDDを外付けのUSB 3.0ドライブにバックアップするために、Ubuntuサーバーシステムで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)

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

私は何も変更していないと言っていましたが、それはまったく当てはまりません。バックアップしているドライブの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ではありません。バックアップが失敗するのは最大のものの1つでもありません。7530ファイルが含まれています。

EDIT3：

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

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

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

linuxubuntufilesystemsrsync
12
dummzeuch

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

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

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

4
dummzeuch

残っているiノードの2％を見て、EXTファイルシステムが課しているルート予約について考えさせられました。これらをチェックしてみてください：

  1. " ファイルシステムのルート用に予約されたスペース-なぜですか？ "
  2. " OS以外のディスクの「ファイルシステム予約ブロック」の適切なサイズ？ "

古いバックアップの一部を.tar.gzして、使用中のiノードの数が減ることを期待しています。

4
Vlad GURDIGA

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

これは、ext4ファイルシステムでフォーマットされたブロックデバイスでのハッシュの衝突が原因で発生します。特に、ディレクトリインデックスが有効になっていて、単一のディレクトリが100kを超えるファイルをホストし、ファイルの名前が同じアルゴリズムから生成されている場合（キャッシュファイル、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

乾杯。

3
VaLentin ChernoZemski

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

したがって、これはあまり役に立ちません-しかし、バックアップデバイスでext4を試してみませんか？

1
Rafiq Maniar

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

 fs.inotify.max_user_watches = 100000

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

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

1
Sirex

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

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

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

実際、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).

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

0
João Carlos Mendes Luís