700k のファイルを同じ FS 内の単一のディレクトリに移動すると、デバイスに空き容量がなくなる

700k のファイルを同じ FS 内の単一のディレクトリに移動すると、デバイスに空き容量がなくなる

次のコマンドを使用して、サーバー上の膨大な数のファイルを検索して移動します。

find SomeDir/ -maxdepth 10 -type f -mtime +90 -exec mv {} SomeDir2/ \;

約 700,000 個のファイルを移動した後、次のエラーが発生します。

mv: cannot move ‘SomeDir/Dir1/Dir2/Dir3/file.jpg.gz’ to ‘SomeDir2/file.jpg.gz’: No space left on device

df -i結果は次のようになります。

/dev/sdb1           322125824 144163358 177962466   45% /files

df -h結果は次のようになります。

/dev/sdb1            4.8T  3.5T  1.1T   78%   /files

私はすべての操作を/files他のディレクトリで行いません

ファイルシステムは ですext4

アップデート

提案されたとおりに実行したdmesg -Hwxところ、出力は次のようになりましたEXT4-fs warning (device sdb1): ext4_dx_add_entry:2016: Directory index full!

答え1

max_dir_size_kbディレクトリのマウント時に設定を超過している(またはデフォルトのままになっている)可能性があります。

Linux ドキュメント:

max_dir_size_kb=n
    This limits the size of the directories so that any
    attempt to expand them beyond the specified limit in
    kilobytes will cause an ENOSPC error. This is useful in
    memory-constrained environments, where a very large
    directory can cause severe performance problems or even
    provoke the Out Of Memory killer. (For example, if there
    is only 512 MB memory available, a 176 MB directory may
    seriously cramp the system's style.)

(はENOSPCエラーメッセージに変換されNo space left on deviceますperror)

したがって、マウント時にオプションが指定されていないこと (または非常に大きな数値が指定されていないこと) を確認してください。

また、コメント:

  • 1 つのフォルダーにファイルが多すぎるのは、あまり良い考えではないようです。代わりにリレーショナル データベースが必要でしょうか? オブジェクト ストレージでしょうか?
  • 4.8 TB: これは最近のハード ドライブでは珍しいことではありませんが、正直なところ、この時代に何かをセットアップするときは、LVM などのストレージ プールを使用してください。これにより、ライブ システムのスナップショットなどを作成できます。

答え2

新たに得られた情報によると:

したがって、git タグ v3.10 (つまり、カーネル) の linux/fs/ext4/namei.c の 2007 行目を読むと、運が悪かったようで、ファイルシステムを調整する必要があると思います。

tune2fs -O large_dir /dev/sdb1

ディレクトリごとにさらに多く設定できるはずですdx_entriesが、正直に言うと、私はそうしたことはありません。いつものように、バックアップを取ってください。

バックアップがあることを確認するか、同じファイル システム内でファイルを移動するのではなく、これらのファイルをコピーする新しいファイル システムにこれを適用してください。私が XFS ファンであるかのように思われるかもしれませんが (そうではありません。動作するだけです)、調整されていない ext4 がこのユース ケースに最適なファイル システムであるようには思えません。

関連情報