Google文件系统是否允许列出目录内容?

时间:2014-05-30 23:54:53

标签: database database-design file-io consistency gfs

在GFS文件中,第4.1节描述了GFS如何能够在目录中进行并发突变,同时只需要对每个客户端的目录进行读锁定 - GFS中没有实际的inode,因此客户端是免费的创建,删除或改变/x/y/somefile,同时只需要/x//x/y/上的读锁定。

如果没有inode,那么仍然可以维护一个显式的树结构吗?我能看到这个工作的唯一方法是,如果主服务器维护从目录或文件名到其元数据的扁平的1维映射,允许快速创建文件和操作。

假设GFS的某个客户端想要扫描目录中所有文件的名称 - 例如ls。如果不对所有元数据节点进行迭代,这怎么可能?

客户端可能有可能在GFS中维护他们认为目录树的外观版本,但这只有在每个客户端都保存到自己的目录时才有效。

1 个答案:

答案 0 :(得分:1)

主查找表提供对节点的单个概念的访问。它通过将所有名称路径列出到节点来实现此目的。一些节点是目录。唯一的数据由非目录叶节点拥有。例如这些路径:

/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-”和“Unix / Linux-”放在每个技术术语的前面,而不是那些引用命名节点树的那些术语。

编辑:示例。

1

  

假设GFS的某个客户端想要扫描所有文件的名称   在目录中 - 例如,ls。没有迭代全部   元数据节点,这怎么可能?

目录列表将返回查找表中扩展给定目录路径的路径。 GFS将提供文件服务器命令来执行此类操作或支持执行此类操作,隐藏其实现。能够遍历查找表就足够了(但很慢)。例如ls / a / b:

/a/b/foo
/a/b/c/bar

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