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

Question

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

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

下次用户想要从/foo/bar列出文件时，后端将返回数据缓存服务器中的条目，而不是通过内核调用执行磁盘I / O，假设/foo/bar中的文件没有＆＃ 39;自上次查询以来我发生了变化 - 我可以使用inotify等来监控。

现在，我的问题如下：

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

Answer 1

  

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

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

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

  

  
1. 使用大量文件时，与Redis服务器通信的开销是否与上市目录内容的磁盘I / O相比是否值得？
  

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

如果Redis和磁盘在同一个＆amp;单机，那么无论最终位置是什么，你都要承担网络成本。当你在机器内部时，无论是读还是写，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