Linux 基于数据库而不使用fuse的FS

为了从一个目录中提供数百万个文件，能够从数百个端点连接到一个驱动器，以及出于其他一些原因（为了避免gluster/nfs/all-fs基于网络的解决方案），我想评估创建基于mongodb（或任何其他）的文件系统的可能性

基本上，它像fusefs一样工作，每个文件都保存在mongogridfs中。理论上，我是这样认为的

mount mongodbfs/mountPointmongodb://localhost

然后当我说

touch/mountPoint/test.txt

时，这个文件被插入到mongodb中。这个FS还将存储uid/gid和文件中的PERM，我们可以向它抛出数百个服务器，并且不需要

useradd

。我不想包括FS的所有功能，只是我们需要的功能

我的问题是，我如何开始寻找资源、书籍、链接、人员和开发人员来帮助我实现这一点？至少是一个概念证明。可行吗？我应该期待什么样的时间表来完成这样的任务

请只考虑无数的小文件和文件夹

ps：经过几天的研究，我想这就是我的方向 http://www.flipcode.com/archives/Programming_a_Virtual_File_System-Part_I.shtml

---

我知道这项工作的困难。然而，我们愿意留出一个认真的预算，并愿意组建一个认真的团队来实施它——只有在我们确保这不是一个黑洞（因此这是一个问题）之后。

您在这里最常见的建议是“使用保险丝”。这是一个很好的建议，你最好注意它（正如Sciurus指出的，已经有一个非常接近你想要的）

也就是说，如果你想经历漫长而艰难的痛苦之路（编写自己的文件系统），你几乎肯定会想在当地大学上一门操作系统课程，或者看看一些（“编写一个简单的FS”通常是一个小项目。文件系统通常很糟糕，因为它们是学术玩具）。
接下来是（Moshe Bar）和一些简单文件系统驱动程序的透彻阅读，以了解需要执行的基本框架

---

就时间线而言，如果您是一名优秀的程序员，您可以在几天到一周内编写一个基本的文件系统（但它将糟糕透了）。我甚至猜不出编写一个好的文件系统需要多长时间——UFS/FFS（BSD文件系统）至少从20世纪70年代末到80年代初就一直在持续开发，改进/增强/错误修复仍然偶尔出现。Sun/Oracle的ZFS在其相对较短（6年）的生命周期内已经经历了20多次迭代，尽管不可否认，其中很多都与卷管理功能有关。

此项目与您想要的类似吗？它是类似的，但我们希望它没有保险丝。我相信这是一个以前从未尝试过的完全原创的想法，因为历史上所有其他文件系统设计者都很愚蠢，包括微软的5000人年项目失败。祝你好运！我必须指出这一点：您正在为MongoDB实现一个文件系统后端，并且您担心FUSE开销？与MongoDB访问相比，FUSE非常便宜。我们必须再次问：您是否对此进行了基准测试，并确认FUSE是一个慢点？如果您试图编写一个与VFS层交互的文件系统，这几乎是一个必然的结论——FUSE为您完成了大部分工作：），而我们正试图避免这一成本。但我要说的是，你们认为一个非fuse的实现是不可行的，与其说是“不可行”，不如说是“更多的工作”。请注意，为了提高性能，您可能能够并行化mongo到FUSE接口（线程？）——熟悉FUSE的人可能会告诉您更多……您好，voretaq7。很抱歉用这种奇怪的方式与你联系，但我希望你能帮助我解决一个我现在正在苦苦挣扎的问题。