根据这篇关于Facebook Haystack的文章：
“ 由于NAS设备pipe理目录元数据的方式，将数以千计的文件放在一个目录中是非常不够的，因为目录的块图太大而无法被设备有效地caching，因此，通常会有10多个磁盘操作来检索单个图像在将目录大小减小到每个目录的数百个图像之后，所得到的系统通常将继续执行3个磁盘操作来获取图像：一个将目录元数据读入到存储器中，另一个将inode加载到存储器中，阅读文件内容“。
我假定文件系统目录元数据和inode总是会被操作系统caching在RAM中，而读取文件通常只需要1个磁盘IO。
这是NAS设备特有的“多磁盘IO读取单个文件”问题，还是Linux也有同样的问题？
我打算运行一个Linux服务器来提供图片。 任何方式我可以最大限度地减less磁盘IO的数量 – 理想情况下，确保操作系统cachingRAM中的所有目录和inode数据，每个文件读取只需要不超过1个磁盘IO？
Linux有相同的“问题”。 这里有一篇论文是我两年前发表的一个学生，其中的效果在Linux上显示。 多个IO可以来自多个来源：
在正常的IO模式中，高速caching确实是有效的，并且inodes，目录和数据块以减lesssearch的方式进行分配。 但是，所有文件系统实际共享的正常查找方法对高度随机化的stream量不利。
这里有一些想法：
1）文件系统相关的caching帮助。 大caching将吸收大部分的读取。 但是，如果要将多个磁盘放入一台计算机，则“磁盘与内存”比率会限制caching的数量。
2）不要使用数百万个小文件。 将它们汇总到较大的文件，并将文件名和偏移量存储在文件中。
3）将元数据放置或caching在SSD上。
4）当然，使用一个文件系统，没有一个完全无政府状态的磁盘目录格式。 一个readdir不应该花费超过线性时间，并且直接访问文件只是对数时间。
保持目录很小（less于1000）应该不会有太大的帮助，因为你需要更多的目录需要被caching。
这取决于您打算使用的文件系统。 在读取文件数据系统之前：
如果文件夹包含大量的文件，这对caching来说是一个很大的提示。
您可能无法将所有目录和inode数据保留在RAM中，因为您的目录和inode数据可能比RAM更多。 你也可能不想，因为RAM可能会更好地用于其他目的; 在你的图像的例子，你不喜欢有一个经常访问的图像caching在RAM中的数据比目录条目不常访问的图像？
这就是说，我认为vfs_cache_pressure旋钮是用来控制这个的。 “当vfs_cache_pressure = 0时，由于内存压力，内核将永远不会回收更改和inode，这很容易导致内存不足的情况。”