分布式文件系统的设计 2

命名空间 －－ 网络拓扑的设计？

人对一个文件系统最直观的感受，（元数据的访问）应该是目录树的形式。但是目录树

这种集权形式，确必然不适合分布式文件系统。因为这很可能要求在一台机器上存在整

个元数据的完整拷贝。否则会有什么后果呢？ 由多台机器上的分支组成树，这样在一致

性，容错 性能？ 上，似乎根本无能为例。

但是，我们希望树这种人类思维的逻辑，不要参与到这个系统中，得救之道还是分布式， 我们让

客户端更多的承担一致性，路径查找，甚至日志，缓存 方面的责任，而整个文件系统，将会是个

很简单的东西，简单到人类无法理解，如同010101一串数据。设计的原则一： 系统核心，与用户

的视图，逻辑无关！ 

    fid = MD5(path)_NUM;

这样，对于文件系统来说，所有文件路径的长度都是一样的，没有什么 MAX_PATH 255 这种比较恶心的

东西。 文件路径由客户负责，用户请求文件的时候，只请求fid, 而不会请求别的!.  不再存在元数据

服务器，而只存在 元路径服务器。 什么意思呢？ 当客户不存在这样的路径的时候，会需要向原路径

服务器load路径。但是原路径服务器，除了维护一颗目录树以外，其他啥也不干。这样的设计，想起来

是很优美的，但是至少会有下面一些问题:

    1.冲突

    2.一致

    3.这里的客户，指的是什么呢？

冲突比较好解决，一致性，只有代码写起来，才能明白。 客户是什么呢？

这里的客户定位于： 使用文件系统接口的应用程序。这里的一个问题是：假设是一个web服务器，作为文件系统嗯的客户端，来使用文件系统。 如果文件系统负责路径到文件 id的映射， 那么应用会很轻松，如果由应用来

维护文件系统的这个映射？这里肯定是不可能的？ （关键是一个web server 无法承受这么大数据量的路径信息的维护？ XX，这应该不是个问题。 这个大数据量路径信息的维护，交给本地文件系统维护？） 不过这样的设计，如果客户端更小，比如是一个手机终端用户，迅雷用户？ 就好了。因为他需要维护的数据，是很有限制的。

（这个人如何访问别人的文件呢？ 不允许他知道别人的路径，但他有可能知道别人的MD5，或者随意尝试MD5?? 

这个问题，也不由文件系统解决，而由文件系统，和 客户端之间的一个安全层来解决。这个安全层，仅仅负责：

验证，转发 消息。

。。。。待续