我有一個包含約 200 萬個符號連結的目錄，這些符號連結指向同一驅動器上的真實文件，該驅動器是真正的本地硬碟（不是網路安裝）。檔案名稱都是唯一的，它們指向的檔案分散在不同的目錄中，但它們都共享相同的父路徑。我正在使用符號連結合併多個目錄中的檔案。
/some/full/path/consolidated/my_file -> /some/full/path/mydir2/my_file
/some/full/path/consolidated/my_file2 -> /some/full/path/mydir3/my_file2
/some/full/path/consolidated/my_file3 -> /some/full/path/mydir4/my_file3
/some/full/path/consolidated/my_file4 -> /some/full/path/mydir4/my_file4
/some/full/path/consolidated/my_file5 -> /some/full/path/mydir2/my_file5
/some/full/path/consolidated/my_file6 -> /some/full/path/mydir3/my_file6
保證符號連結不會被破壞。
問題是
time find "/some/full/path/consolidated/" -maxdepth 1 -type l -print > /tmp/foo
很快完成：
1.24 user 0.83 system 0:02.08elapsed
然而，
time find -L "/some/full/path/consolidated/" -maxdepth 1 -type f -print > /tmp/foo
其次是
watch wc -l /tmp/foo
顯示它很快就達到了約 660,000 行，然後就停止了，時不時地添加數千個結果。
為什麼它可能會停滯？是否有可能使第二個命令像第一個命令一樣快？
編輯： 根本/tmp沒有出現mount（所以我認為它不是 tmpfs）。根據 htop 的說法，我的記憶體並不低；我還有大約 50GB 的可用空間。 CPU使用率也很低。當速度變慢時，find -L path停止運轉的大約為 90MB。/tmp/foo對於find path，它不會停止，大小/tmp/foo為 111MB。
將輸出重定向到 ~/foo 時，我也有相同的速度減慢。
編輯：當目測時iotop，find -L列出了 99.99% 的 I/O，但僅在大約 10 秒後，這遠遠晚於正常find完成。
答案1
試著增加你的 inode 緩存
echo 50 | sudo tee /proc/sys/vm/vfs_cache_pressure
值 100 是平均值，較低的值 = 較大的 inode+dentry 快取
缺點：較大的快取可以慢一些，所以你也可以嘗試減少緩存
echo 200 | sudo tee /proc/sys/vm/vfs_cache_pressure
或者您可以使用快取檔案列表
sudo updatedb
locate /some/full/path/consolidated
也要注意 inode 使用情況，符號連結佔用 inode（硬連結也是如此）
df -i
有關的：https://serverfault.com/questions/338097/tuning-linux-cache-settings-for-inode-caching