基于数据库的FS,不使用保险丝
收藏

为了从一个目录中服务数百万个文件,能够从数百个端点连接到一个驱动器,并且出于某些其他原因(为了避免基于gluster/nfs/all-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
我知道这项工作有困难。然而,我们愿意留出一个认真的预算,并愿意组成一个认真的团队来执行它-只有在我们确保这不是一个黑洞(因此问题)。


最佳答案:

你最常听到的建议是“使用保险丝”。这是一个很好的建议,你最好听从它(正如sciurus所指出的,已经有了gridfs-fuse这是非常接近你想要的)。
也就是说,如果你想走一条漫长而艰难的痛苦之路(编写自己的文件系统),你几乎肯定想在当地大学上一门操作系统课程,或者看看一些online course materials(“编写一个简单的fs”通常是一个小项目)。文件系统通常很糟糕,因为它们是学术玩具)。
接下来是Linux File Systems(moshe bar)和一些简单文件系统驱动程序的详细阅读,以了解需要做什么的基本框架。
就时间线而言,如果你是一个优秀的程序员,你可以在几天到一周内编写一个基本的文件系统(但这会很糟糕)。我甚至都猜不到写一个好的文件系统需要多长时间——UFS/FFS(BSD文件系统)至少从20世纪70年代末/80年代初开始就在不断开发中,改进/增强/错误修复仍然偶尔出现。sun/oracle的zfs在其相对较短(6年)的生命周期中经历了20多次迭代,尽管不可否认,其中大部分与卷管理功能有关。

公众号