linux - 文件系统 : Kernel calls vs. 缓存

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. Does this architecture make sense, or the Linux kernel/file-system/etc. already takes care of caching?

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

因此从磁盘卸载一些工作确实有意义。

2. Is the overhead of communicating with a Redis server worth it when working with a lot of files, versus the disk I/O of listing directory contents?

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

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

有关更多信息，请参阅此 answer

Numbers Everyone Should Know

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