这个问题来自另一个问题。
我目前发现我的磁盘存在一些性能问题,统计数据显示 16-43% 的目录不连续,0.42-13% 的文件不连续。
在文件部分,我认为我已经拥有它:我已经调整了我的过程以一次预分配整个文件然后在其上写入,以便文件系统可以正确分配它。
但是对于文件夹碎片,我不知道为什么会发生这种情况,也不知道如何在经常创建和删除文件时避免它。
任何想法?
什么对目录遍历(和文件stat()
)影响更大?文件还是目录碎片?
有没有其他文件系统比这个用例表现得更好?(固定深度的文件夹中有大量/数百万个小文件)
答案1
我敢说,问题实际上并不在于文件夹碎片。问题在于 stat(2) 系统调用需要查找来读取 inode。对于非常大的目录,inode 编号往往到处都是,如果它们不在缓存中,则每个 inode 的每次 4k 随机查找都会很痛苦。例如,比较运行以下命令的时间:
# echo 3 > /proc/sys/vm/drop_caches
# time /bin/ls /path/to-really-large-directory > /dev/null
和:
# echo 3 > /proc/sys/vm/drop_caches
# time /bin/ls -s /path/to-really-large-directory > /dev/null
如果您让用户空间程序按 inode 顺序对 readdir() 返回的文件进行排序,这有时会有所帮助。可以找到一种使用 ld 预加载来拦截 readdir() 调用的方法这里。此外,如果事实证明您的程序不需要 stat(2) 文件,或者您可以找到一种方法来避免需要 stat(2) 文件 --- 例如,如果您有一个方便的别名,以便“ls”变成“ls -sF”,这样您就可以自动显示文件大小和类型,请注意这是有代价的。如果您正在查看一个非常大的目录,或者使用 NFS 或 Ceph 位于远程服务器上的大型目录,那么放弃该别名或养成使用 /bin/ls 的习惯来避免在查看这个非常大的目录时使用别名可能是一个好主意。