在 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. 将源节点子节点复制为目标节点子节点： 对于扩展源路径的每个路径，将通过用目标路径替换该前缀获得的路径添加到查找表。据推测，创建新节点的复制命令会复制非目录的关联数据。例如，将 /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/