首先，我的用例：在我的 Linux 服务器上，小文件的磁盘 IO 性能不令人满意，并且限制在 7200rpm HDD 支持的大约 100 IOPS。这当然是意料之中的，我正在寻找一种提高性能的方法。这尤其成问题，因为我正在处理包含 10,000 个源文件和对象的代码库。总数据量对于 SSD 来说并不经济。无法分离大文件（占用大部分存储空间）和小文件。
典型的解决方案是使用像 lvmcache 这样的缓存系统，但据我理解，在标准配置中，它只会为经常使用的文件提供性能优势（如果我错了，请纠正我！）。这不适合我的用例。这些文件的访问非常随机且很少。
因此问题是：是否可以配置缓存来预取小文件，这有意义吗？它们只占总存储利用率的一小部分，完全可以放在 SSD 上。我希望它们永久存在，以便按需访问。我认为没有内在的技术问题，但我找不到任何此类记录行为，除了一些超级计算机数据存储系统 ^^
答案1
量化可接受的性能。也许下载一个小型项目的全部内容只需一两秒。根据用户体验定义性能目标有助于明确目标。
检查文件的存储方式。最糟糕的情况是数以万计的文件，文件和元数据有大量的 IO。数据库或档案库会更好，可以打包成更大的包，减少 IO。换句话说，版本控制系统和档案库 tar，尤其是在处理随时间推移的代码时。
在 Linux 中，开发人员喜欢重新发明轮子。因此，有许多块缓存实现，其中维护最多的可能是 lvmcache 和 bcache。至少，这两个都是主线内核，因此像这样的比较测试.虽然看起来RHEL 尚未准备好支持 bcache。
混合块设备不可能像全闪存设备一样快速或易于使用。缓存会丢失。缓存设备会出现故障，此时您最好知道它是处于写通模式还是写回模式，以及恢复是否会导致数据丢失。这些都是为了降低整体存储成本而做出的权衡。
这些是块设备，它们位于文件系统的下一级，并且无法感知小文件。但是，根据您想要进行调优的深度，它们可能能够检测连续的块 I/O。这可能是一个可接受的代理，具体取决于文件的碎片程度。
具有良好存储文档的发行版将涵盖 lvmcache。以下是RHEL 9 中的 lvmcache 示例。您可能想要类型缓存，仅通过 writecache 进行写入将无法获得足够的提升。
请注意，底层 dm-cache 可调参数提到了“sequential_threshold”，但这没有效果。现代内核用更快的缓存替换策略替换了缓存替换策略，但没有旋钮。
块缓存没有预取机制，尤其是针对目标文件子集。同样，块层不知道文件。某些东西需要执行 I/O 才能知道某些东西是热门的。翻阅 Server Fault 档案，有些人有通过读取文件预热缓存。
请注意，RAM 仍然比固态硬盘快，而且 Linux 始终维护文件缓存。更多 RAM 将增加此缓存的工作集，但请注意，一开始它需要很慢，直到命中率提高。不过，我建议在投入过多 RAM 来解决这个问题之前，先投资全闪存。
答案2
vmtouch尝试使用(将它们固定到 vcache 中https://hoytech.com/vmtouch/）。只要有足够的 RAM，它就会加快文件的访问时间。
另外，考虑一下 SSD - 价格最近一直在下降。