我使用以下命令在我的伺服器上尋找並移動大量檔案:
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
因此,請確保在安裝時未指定該選項(或指定了非常大的數字)。
另外,備註:
- 一個資料夾中的文件太多聽起來不是一個好主意。您可能想要一個關係資料庫嗎?對象存儲?
- 4.8 TB:這對於現代硬碟來說並不罕見,但老實說,下次在當今時代設定某些東西時,請使用像 LVM 這樣的儲存池。這樣你就可以獲得諸如即時系統快照之類的東西。
答案2
根據新獲得的資訊:
所以,閱讀 git tag v3.10 中的 linux/fs/ext4/namei.c line 2007 (即你的核心),我認為你有點運氣不好,需要調整你的檔案系統;
tune2fs -O large_dir /dev/sdb1
應該允許你每個目錄有更多的內容dx_entries
,但老實說,我從來沒有這樣做過。像往常一樣,做好備份。
確保您有備份,或將其套用到將這些檔案複製到的新檔案系統,而不是在同一檔案系統中移動它們。這可能會讓我覺得我是一個 XFS 粉絲(我不是,它只是有效),但我認為這聽起來確實不像一個未調整的 ext4 對於這個用例來說是一個很好的檔案系統。