在GFS的论文中，第4.1节描述了GFS如何能够在一个目录内进行并发突变，而只需要对每个客户端都有读锁——GFS中没有实际的索引节点，所以客户端可以自由地创建、删除或突变/x/y/somefile，而只需要对/x/和/x/y/有读锁。
如果没有节点，那么还能维持显式的树结构吗?我能看到这个工作的唯一方法是，如果主服务器维护一个从目录或文件名到它们的元数据的扁平的、一维的映射，允许快速的文件创建和操作。
假设GFS的某个客户端想要扫描目录中所有文件的名称——例如，ls。如果不对所有元数据节点进行迭代，这怎么可能呢?
对于客户端来说，维护他们自己认为的GFS目录树的版本是可能的，但这只有在每个客户端都保持自己的目录时才能工作。
主查找表提供对节点的单个概念树的访问。它通过列出名称到节点的所有路径来实现这一点。有些节点是目录。唯一的数据由非目录叶节点拥有。例如这些路径:
/a/b/foo
/a/b/c/bar
/a/baz/
描述树:
a/--b/--foo
|
| c/--bar
baz/
每条路径标识一个节点。作为节点子节点的节点是那些在查找表中路径长一个名称的节点。列出节点的子节点就是列出查找表中比其路径长一个名称的所有路径。本文所说的metatdata是指节点是否锁定以及如何锁定，以及非目录叶节点的(非共享)数据所在位置。
不像在Unix/Linux中那样，通过访问拥有子节点和父节点名称以及它们是否为目录的数据的目录节点来导航。复制一个叶子意味着将它的数据复制到另一个叶子上，像Unix/Linux的cat，而不是cp。我认为可以复制一个子树，这将在查找表中添加新的路径，并复制非目录叶子的数据。
不能把"文件"或"目录"这样的专业术语当作它们在两个系统中的意思一样来使用。我们可以做的是考虑GFS和Unix/Linux都管理通过目录节点到目录叶子和非目录数据所属叶子的相同类型的名称路径树。但在此之后，文件系统状态的其他部分(元数据和数据)及其操作符就不同了。在你的脑海中，把"GFS-"one_answers"Unix/Linux-"放在每一个技术术语的前面，而不是那些指命名节点树的术语。
编辑:例子。
1。
假设GFS的某个客户端想要扫描所有文件的名称在目录中——例如，ls。完全不需要迭代元数据节点，这怎么可能?
目录列表将返回查找表中扩展给定目录路径的路径。GFS将提供文件服务器命令来做这些事情或支持做这些事情，隐藏其实现。能够遍历查找表就足够了(但速度很慢)。例如ls/a/b:
/a/b/foo
/a/b/c/bar
2。要将源节点子节点复制为目标节点子节点:对于扩展源路径的每个路径，将通过用目标路径替换前缀而获得的路径添加到查找表中。创建新节点的copy命令可能会为非目录复制相关数据。例如copy/a/children to/a/b/c/add:
/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/