我正在运行find . -type d find . -type d在一个相当大的目录树上。 我只对在这棵树里find目录感兴趣，但是当我对进程运行一个strace以确保它正在做我期望的操作时，我注意到有大量的操作被浪费在运行fstat的文件上在树内。
newfstatat(AT_FDCWD, "file1", {st_mode=S_IFREG|0600, st_size=7690, ...}, AT_SYMLINK_NOFOLLOW) = 0 newfstatat(AT_FDCWD, "file2", {st_mode=S_IFREG|0600, st_size=7696, ...}, AT_SYMLINK_NOFOLLOW) = 0 newfstatat(AT_FDCWD, "file3", {st_mode=S_IFREG|0600, st_size=7687, ...}, AT_SYMLINK_NOFOLLOW) = 0 newfstatat(AT_FDCWD, "file4", {st_mode=S_IFREG|0600, st_size=10455, ...}, AT_SYMLINK_NOFOLLOW) = 0
发现不知道一个inode指向一个目录，直到它执行一个fstat？ 如果是这样的话，这将需要很长时间。 其中的一些目录可能有数以百万计的内容，但我真的只关心目录。
最终，我想要在我的文件树中的每个目录的dirsize和path的报告。 什么是最快/最有效的方式来做到这一点？
是的，它看起来确实是这样的，find是使用fstat来确定文件的types。 鉴于dirent自kernel 2.6.4以来已经包含了这些信息，所以这是相当有意思的。
并不是所有的文件系统都支持扩展的dirent行为，所以在你的情况下这是真的，或者发现不使用它。 不知道你的文件系统types，我们不能决定。
我相信你知道，在UNIX范例中，目录是一种特殊types的文件。 要确定是否某个目录或其他types的文件，它必须被询问，而fstat（）是一个很好的方法来做到这一点。
我相信以后的文件系统和fs-drivers会保留一个单独的目录表，但find命令可能要追溯到几十年，可能不适应新的文件系统，或者保持向下的兼容性。
你可以通过在CRON中运行一个循环的工作（假如你想简化其他进程的IO利用率）来伪造这个假设，
find$ {DIRECTORY} -type d -print> $ {DIRECTORY} /。only_folders
然后，当你需要这个时，使用你预build的文件的内容，而不是再遍历目录。
猫“$ {DIRECTORY} /。only_folders”|阅读FOLDER; 做
do_work.sh $ {FOLDER};
DONE
而不是类似的东西
find$ {DIRECTORY} -type d | xargs do_work.sh