为了从单个目录中提供数百万个文件，能够从数百个端点连接到驱动器，以及出于其他一些原因(为了避免基于 gluster/nfs/所有 fs 的网络解决方案)，我想评估使基于 mongodb(或任何其他)的文件系统。
基本上，它的工作原理类似于 fusefs，每个文件都保存在 mongo gridfs 中。理论上，我确实，mount mongodbfs /mountPoint mongodb://localhost
然后当我说 touch /mountPoint/test.txt 这个文件被插入到 mongodb 中。这个 FS 还将与文件一起存储 uid/gid 和 perms，我们可以将数百个服务器扔给它，并且不需要 useradd。我不考虑包含 FS 的所有功能，只是我们需要的功能。
我的问题是，我如何开始寻找资源、书籍、链接、人员、帮助我实现这一目标的开发人员？至少是一个概念证明。可行吗？作为此类工作的时间表，我应该期待什么？
请只考虑无数的小文件和文件夹。
ps:经过几天的研究，我认为这是我前进的方向
http://www.ibm.com/developerworks/library/l-sc12.html
http://www.flipcode.com/archives/Programming_a_Virtual_File_System-Part_I.shtml
ps2:我知道这项工作的难度。但是，我们愿意留出认真的预算，并愿意组建一个认真的团队来实现它——只有在我们确保这不是一个黑洞之后(因此是问题)。
最佳答案
您在这里最常见的建议是“使用 FUSE”。这是一个很好的建议，你最好注意它(正如 Sciurus 指出的那样，已经有 gridfs-fuse 非常接近你想要的)。
也就是说，如果你想走漫长而艰难的痛苦之路(编写你自己的文件系统)，你几乎肯定想在本地大学上一门操作系统类(class)，或者看看一些 online course materials(“写一个简单的 FS "通常是一个小项目。文件系统通常很糟糕，因为它们是学术玩具)。
继续使用 Linux File Systems (Moshe Bar) 并彻底阅读一些简单的文件系统驱动程序，以了解您需要执行的操作的基本框架。
至于时间线，如果你是一个体面的编码员，你可以在几天到一周内编写一个基本的文件系统(但它会 SUCK )。我什至不知道编写一个好的文件系统需要多长时间——UFS/FFS(BSD 文件系统)至少从 1970 年代末/1980 年代初以来一直在不断发展，改进/增强/错误修复仍然流行偶尔起来。 Sun/Oracle 的 ZFS 在其相对较短(6 年)的生命周期中经历了 20 多次迭代，但不可否认其中大部分与卷管理功能有关。
关于linux - 基于数据库的FS不使用fuse，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/5222432/