基于数据库的文件系统，不使用fuse

Question

基于数据库的文件系统，不使用fuse

4

为了从单个目录中服务数百万个文件，能够从数百个终端连接到驱动器，并且出于其他一些原因（避免gluster/nfs/所有基于文件系统的网络解决方案），我想评估基于mongodb（或任何其他）的文件系统的可能性。基本上，它的工作原理类似于fusefs，每个单独的文件都保存在mongo gridfs中。理论上，我可以使用以下命令： mount mongodbfs /mountPoint mongodb://localhost 然后当我输入 touch /mountPoint/test.txt 时，这个文件就会被插入到mongodb中。此文件系统还将存储文件的uid/gid和权限，我们可以将数百台服务器放到其中，而不需要进行用户添加操作。我并不打算包含所有FS的功能，只需要我们需要的那些。

我的问题是，如何开始寻找资源、书籍、链接、人员、开发者来帮助我实现这个目标？至少要有一个概念验证。这可行吗？这样的任务应该预计多长时间？

请考虑亿万个小文件和文件夹。

附注：经过几天的研究，我认为这是我要走的方向 http://www.ibm.com/developerworks/library/l-sc12.html http://www.flipcode.com/archives/Programming_a_Virtual_File_System-Part_I.shtml

附注2：我意识到这项任务的难度。然而，只有在确保这不是一个黑洞之后，我们才愿意投入严重的预算并组建一个严肃的团队来实现它（因此提出问题）。

- Devrim

1

这个项目是否与您想要的 https://github.com/mikejs/gridfs-fuse 相似？ - sciurus

它类似，但我们不想使用FUSE。 - Devrim

5

我相信这绝对是一个全新的想法，从未被尝试过，因为历史上所有其他文件系统设计者都很愚蠢，包括微软耗费了5,000人年的失败项目。祝你好运！ - Chopper3

1

我必须指出：你正在为MongoDB实现一个文件系统后端，而你担心FUSE的开销？与MongoDB访问相比，FUSE的开销非常小。 - Zan Lynx

2

我们不得不再次问一遍：您是否对此进行了基准测试并确认FUSE是瓶颈？ - pjc50

显示剩余6条评论

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- voretaq7 · Accepted Answer

你最常提供的建议是“使用FUSE”。这是很好的建议，你最好遵从（正如Sciurus指出的那样，已经有了gridfs-fuse，它非常接近你想要的）。

话虽如此，如果你想走漫长而艰难的道路（编写自己的文件系统），你几乎肯定要在当地大学参加操作系统课程，或者查看一些在线课程材料（“编写一个简单的FS”通常是一个小项目。这些文件系统通常很糟糕，因为它们只是学术玩具）。接着阅读Linux文件系统（Moshe Bar）和一些简单的文件系统驱动程序以查看你需要做的基本框架。

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