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

Question

我想为教育目的编写一个文件管理器。我打算将软件拆分为后端和前端。后端会像这样进行文件系统缓存：

1. 用户在前端双击目录/foo/bar
2. 后端接收来自前端路径/foo/bar的文件列表查询
   • 使用readdir() 从磁盘/foo/bar 读取文件条目
   • 将条目存储在数据缓存服务器 (Redis) 中
   • 将结果返回到前端
3. 前端显示/foo/bar中的文件列表

下一次用户想要列出来自/foo/bar 的文件时，后端将从数据缓存服务器返回条目，而不是通过内核调用进行磁盘 I/O，假设 /foo/bar 中的文件自最后一个查询 - 我可以使用 inotify 之类的内容进行监控。

现在，我的问题如下：

1. 这种架构是否有意义，或者 Linux 内核/文件系统/等。已经负责缓存了吗？
2. 在处理大量文件时，与列出目录内容的磁盘 I/O 相比，与 Redis 服务器通信的开销是否值得？

Answer 1

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

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

所以从磁盘上卸载一些工作是有意义的。

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

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

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

欲了解更多信息，请参阅answer

每个人都应该知道的数字

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