基于数据库的FS，不使用fuse
为了从单个目录中提供数百万个文件，能够从数百个端点连接到驱动器，并且出于其他一些原因（为了避免基于 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
ps2：我知道这项工作的难度。然而，只有在我们确保这不是一个黑洞（因此是问题）之后，我们才愿意拨出大量预算并愿意组建一个认真的团队来实施它。
To serve millions of files out of a single directory, being able to connect to a drive from hundreds of endpoints, and for some other reasons (to avoid gluster/nfs/all fs based networking solutions), I want to evaluate the possibility of making a filesystem that's based on a mongodb (or any other).
Basically, it works like fusefs, every single file is kept in mongo gridfs. In theory, I do,
mount mongodbfs /mountPoint mongodb://localhost
then when i say touch /mountPoint/test.txt this file is inserted into mongodb. This FS will also store uid/gid and perms with the file, we can throw hundreds of servers to it, and no useradd will be necessary. I'm not thinking to include all the features of FS, just the ones we need.
My question is, how do I start my quest in finding resources, books, links, people, developers who'd help me implement this? at least a proof of concept. Is it feasible? What should I expect as a timeline for such undertaking?
Please only think about gazillion small files and folders.
ps: after a few days of research i think this is the direction i'm heading
http://www.ibm.com/developerworks/library/l-sc12.html
http://www.flipcode.com/archives/Programming_a_Virtual_File_System-Part_I.shtml
ps2: i'm aware of the difficulty of this undertaking. however we're willing to set aside a serious budget and willing to form a serious team implementing it - only after we make sure that this isn't a black hole (thus the question).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您最常提出的建议是“使用 FUSE”。这是极好的建议，您最好注意它（正如 Sciurus 指出的那样，已经有 gridfs-fuse 这非常接近你想要的）。
也就是说，如果您想走上漫长而艰难的痛苦之路（编写自己的文件系统），您几乎肯定想在当地大学学习操作系统课程，或者看看一些在线课程材料（“编写一个简单的文件系统”通常是一个小项目。文件系统通常很糟糕，因为它们是学术玩具）。
接下来是 Linux 文件系统 (Moshe Bar) 并彻底阅读一些简单的文件系统驱动程序来查看您需要执行的操作的基本框架。
就时间表而言，如果您是一名不错的编码员，您可以在几天到一周内编写一个基本的文件系统（但它会糟糕）。我什至猜不到编写一个GOOD文件系统需要多长时间——UFS/FFS（BSD文件系统）至少从20世纪70年代末/1980年代初就一直在持续开发和改进/enhancements/bug 修复仍然偶尔会弹出。 Sun/Oracle 的 ZFS 在其相对较短（6 年）的生命周期中已经经历了 20 多次迭代，尽管不可否认其中大部分与卷管理功能有关。
Your most frequent piece of advice here is going to be "Use FUSE". This is excellent advice, and you would do well to heed it (As Sciurus pointed out there's already gridfs-fuse which is pretty close to what you want).
That said, if you want to take the long, hard road of pain and suffering (writing your own filesystem), you almost certainly want to take an operating systems course at a local university, or look at some online course materials ("Write a simple FS" is usually a small project. The filesystems typically suck because they're academic toys).
Follow that up with Linux File Systems (Moshe Bar) and a thorough reading of some simple filesystem drivers to see the basic skeleton of what you'll need to do.
As far as timeline, if you're a decent coder you can write a basic filesystem in a few days to a week (but it will SUCK). I wouldn't even guess how long it would take to write a GOOD filesystem -- UFS/FFS (the BSD filesystem) has been under continuous development since at least the late 1970s/early 1980s, and improvements/enhancements/bug fixes still pop up occasionally. Sun/Oracle's ZFS has gone through over 20 iterations in its relative short (6-year) life, though admittedly much of that is related to volume management capabilities.