在GFS论文中，第4.1节描述了GFS如何能够在目录内进行并发突变，而只需要为每个客户端对目录进行读锁定-GFS中没有实际的inode，因此客户端可以自由创建，删除或变异/x/y/somefile而只需要对/x/和进行读取锁定/x/y/。
如果没有inode，那么是否仍然可以维护显式树结构？我能看到此工作的唯一方法是，如果主服务器维护从目录或文件名到其元数据的扁平的一维映射，则可以快速创建和操作文件。
假设某个GFS客户端希望扫描目录中所有文件的名称，例如ls。如果不对所有元数据节点进行迭代，这怎么可能？
客户端可能会维护自己认为的目录树在GFS中的版本，但这仅在每个客户端都保留其自己的目录时才有效。
一个主查询表提供了访问单一的概念树的节点。它通过列出节点的所有名称路径来做到这一点。一些节点是目录。唯一的数据归非目录叶节点所有。例如，这些路径：
/a/b/foo
/a/b/c/bar
/a/baz/
描述这棵树：
\
a/--b/--foo
| \
| c/--bar
baz/
每个路径都标识一个节点。作为节点的子节点的节点是在查找表中其路径长一个名称的节点。列出节点的子节点就是列出查找表中所有比其路径长一个名称的路径。本文对元数据的含义是信息，例如是否锁定节点以及如何锁定节点以及针对其（未共享）数据所在的非目录叶节点。
就像在Unix / Linux中一样，访问目录节点不拥有拥有子节点和父节点名称以及它们是否是目录的数据的导航方式。复制一个叶子意味着将其数据复制到另一个叶子的数据，例如Unix / Linux cat，而不是cp。我假设可以复制一个子树，这将在查找表中添加新路径并复制非目录叶的数据。
一个人不能使用诸如“文件”或“目录”之类的技术术语，就好像它们在两个系统中的含义相同。可以做的就是考虑GFS和Unix / Linux都通过目录节点到目录叶和非目录数据拥有叶来管理同一种名称树。但是之后，文件系统状态的其他部分（元数据和数据）及其运算符会有所不同。在您的脑海中，除了那些引用命名节点的树以外，在每个技术术语的前面都加上“ GFS-”和“ Unix / Linux-”。
编辑：例子。
1。
假设某个GFS客户端希望扫描目录中所有文件的名称，例如ls。如果不对所有元数据节点进行迭代，这怎么可能？
目录列表将返回查找表中扩展给定目录路径的路径。GFS将提供文件服务器命令来执行此类操作或支持执行此类操作，从而隐藏其实现。能够遍历查找表就足够了（但是很慢）。例如ls / a / b：
/a/b/foo
/a/b/c/bar
2.要将源节点子代复制为目标节点子代：对于每个扩展源路径的路径，将通过用目标路径替换该前缀而获得的路径添加到查找表中。大概创建新节点的copy命令复制非目录的关联数据。例如，将/ a /的子级复制到/ a / b / c /会添加：
/a/b/c/b/foo
/a/b/c/b/c/bar
/a/b/c/baz/
给予：
\
a/--b/--foo
| \
| c/--bar
| |--b/--foo
| | \
| | c/--bar
| baz/
baz/
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句