次のコマンドを使用して、サーバー上の膨大な数のファイルを検索して移動します。
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
ディレクトリのマウント時に設定を超過している(またはデフォルトのままになっている)可能性があります。
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 がこのユース ケースに最適なファイル システムであるようには思えません。