Linux 文件系统：内核调用与缓存

我想写一个用于教育目的的文件管理器。我计划将软件分为后端和前端。后端将执行如下文件系统缓存：

用户双击前端的目录

/foo/bar

后端在路径

/foo/bar

• 使用

  readdir（）

• 将条目存储在数据缓存服务器（Redis）中
• 将结果返回到前端

前端在

/foo/bar

下一次，当用户想要列出

/foo/bar

中的文件时，后端将从数据缓存服务器返回条目，而不是通过内核调用执行磁盘I/O，假设

/foo/bar

中的文件自上次查询以来没有更改，我可以使用类似

inotify

的方法进行监视

现在，我的问题如下：

这种架构有意义吗，或者Linux内核/文件系统/等已经负责缓存了

与列出目录内容的磁盘I/O相比，处理大量文件时与Redis服务器通信的开销值得吗

这种架构有意义吗，或者Linux内核/文件系统/等已经负责缓存了

Linux确实在某种程度上负责缓存，它主要与在内存中加载文件（不写入）有关。另外，依靠LINUX来缓存目录意味着你失去了对缓存内容的控制。此外，LINUX缓存取决于许多因素，因为它的目标主要是确保数据一致性，而不是读取性能

因此，从磁盘上卸载一些工作是有意义的

与列出目录内容的磁盘I/O相比，处理大量文件时与Redis服务器通信的开销值得吗

这引发了更多的问题。磁盘是否位于单独的计算机或本地计算机上，以及Redis服务器的位置。它是群集环境还是简单服务器

如果Redis和磁盘在同一台机器上，那么无论终端位置如何，您都必须承担网络成本。当您在机器内部时，无论是读还是写，RAM总是胜过磁盘I/O

有关更多信息，请参见此

每个人都应该知道的数字

---

对我来说没有意义。从Redis获取数据的系统调用数高于从内核缓存获取数据的系统调用数。确实如此，但您可以避免磁盘I/O。有一些选项可以控制Linux的缓存级别。以sysctl vm.vfs_cache_pressure为例，这是正确的，但它不会影响整个Linux系统的使用，而不仅仅是所需的条目。如果OP能对其进行基准测试，谢谢。我得出的结论是，在我决定是否值得付出努力之前，我必须做一些基准测试。我可能会在我的文件管理器原型中实现这两个功能，并亲自查看结果。这是一个好的决定，我很高兴我能够提供帮助：）请发布您的发现！

L1 cache reference                             0.5 ns
Branch mispredict                              5 ns
L2 cache reference                             7 ns
Mutex lock/unlock                            100 ns (25)
Main memory reference                        100 ns
Compress 1K bytes with Zippy              10,000 ns (3,000)
Send 2K bytes over 1 Gbps network         20,000 ns
Read 1 MB sequentially from memory       250,000 ns
Round trip within same datacenter        500,000 ns
Disk seek                             10,000,000 ns
Read 1 MB sequentially from network   10,000,000 ns
Read 1 MB sequentially from disk      30,000,000 ns (20,000,000)
Send packet CA->Netherlands->CA      150,000,000 ns