CN117290298A

CN117290298A - 数据处理方法及相关装置

Info

Publication number: CN117290298A
Application number: CN202211058557.1A
Authority: CN
Inventors: 兰龙文; 程卓; 潘浩; 周文; 程桢; 苏毅
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-06-16
Filing date: 2022-08-30
Publication date: 2023-12-26

Abstract

本申请实施例提供一种数据处理方法及相关装置，应用于存储技术领域。该数据处理方法包括：获取第一文件系统的第一元数据流，该第一元数据流为流式结构且包含多条记录，多条记录中的每条记录包含第一文件系统中的一个节点的标识、一个节点的父节点的标识和一个节点的属性；根据第一元数据流，确定第一文件系统中的多个节点的层次结构。本申请实施例中，统一的流式结构的元数据表达方式，能够拉通异构文件系统之间的元数据，从而使得异构的文件系统中的数据不再是一个个数据孤岛，这会极大地提升用户在数据使用和管理上的便捷性。

Description

数据处理方法及相关装置

技术领域

本申请涉及存储技术领域，尤其涉及数据处理方法及相关装置。

背景技术

非结构化数据一般以文件或者对象的形式存储在文件系统里(本地文件系统或者NAS系统)。异构的文件系统，通常各自通过其访问协议来向外提供文件的读写服务，常见的访问协议例如网络文件系统(network file system，NFS)，Hadoop分布式文件系统(Hadoopdistributed file system，HDFS)，简单存储服务(simple storage service，S3)，服务器信息块(Server Message Block，SMB)等。文件系统中文件的数据内容存储在存储盘中，计算设备可以通过对应的访问协议来访问存储盘中存储的文件的数据内容。

随着用户业务规模的增长，单一的文件系统无法满足业务的需求，用户业务的数据可能会被存储在异构的多个文件系统中。由于异构的文件系统的元数据管理和访问控制方式不同，使得存储在异构的文件系统中的数据变成了数据的孤岛，为用户的数据使用和管理带来极大的不便。

如何解决上述问题，是本领域技术人员正在研究的热点问题。

发明内容

本申请实施例提供了数据处理方法及相关装置，能够以统一的方式来表达异构文件系统的元数据，提升用户在数据使用和管理上的便捷性。

第一方面，本申请实施例提供一种数据处理方法，应用于第一计算设备，包括：

获取第一文件系统的第一元数据流，所述第一元数据流为流式结构且包含多条记录，所述多条记录中的每条记录包含所述第一文件系统中的一个节点的标识，所述一个节点的父节点的标识和所述一个节点的属性；

根据所述第一元数据流，确定所述第一文件系统中的多个节点的层次结构。

可选的，一个节点为一个文件或一个目录。第一文件系统中包含多个节点，这多个节点包含一个或者多个文件，和/或，一个或者多个目录。

流式结构是包含多条记录的一种数据结构，每一条记录包含多个值，每一个值对应了一个字段，流式结构具有以下特征：只读、只增、有序，其中“只读”是指流式结构中的记录的值只能读取而无法修改；“只增”指示流式结构中只能追加新的记录而无法删除已有的记录，但属于同一个节点的多条记录可以被合并成一条记录；“有序”是指流式结构中的记录具有逻辑顺序，追加的记录在流式结构的尾部增加。

可选的，流式结构中的一条记录对应一个节点。进一步的，多条记录可以对应同一个节点。

本申请实施例通过流式结构的元数据流，实现了以统一的方式来表达异构文件系统的元数据，该统一的表达方式能够屏蔽异构文件系统之间元数据管理和访问控制方式的差异，也能屏蔽存储异构文件系统的设备之间的差异。即，通过本申请中统一的流式结构的元数据表达方式，能够拉通异构文件系统之间的元数据，从而使得异构的文件系统中的数据不再是一个个数据孤岛，这会极大地提升用户在数据使用和管理上的便捷性。

并且，由于本申请中统一表达文件元数据的方式是流式结构，该流式结构的“只读”、“只增”和“有序”的特性可以反映出文件系统中的各种变更操作，即本申请中流式结构的元数据的表达方式可以动态地反映文件系统的变化。

在第一方面的一种可能的实施方式中，上述第一文件系统的数据存储在第一存储盘上，第一元数据流来自第二计算设备，所述第二计算设备与所述第二存储盘相连。通过这种方式，通过将异构文件系统的元数据以统一表达方式(流式结构的元数据流)在多个计算设备之间的共享流动，使得多个计算设备都可以方便地根据该流式结构的元数据流确定异构文件系统的层次结构，从而方便地实现某个文件系统的元数据在多个设备之间的互通和共享。例如，第一文件系统的数据存储在第一存储盘上，不仅第二计算设备可以确定第一文件系统的层次结构(第二计算设备与第一存储设备相连，第二计算设备可以访问该第一文件系统的数据并可以确定其层次结构)，当第一计算设备获取到第一文件系统的第一元数据流时，也可以方便地基于第一元数据流确定该第一文件系统的层次结构，并可以基于此构建第一文件系统的文件视图。也就是说，该方式实现了第一文件系统的元数据在第一计算设备和第二计算设备之间的共享和流动，使得用户通过第一计算设备和第二计算设备都可以明确第一文件系统的层次结构(并可以基于此进一步明确包含第一文件系统的层次结构的文件视图)，提升了用户的使用体验。

在第一方面的又一种可能的实施方式中，上述第一计算设备位于第一数据中心，第二计算设备和第一存储盘位于第二数据中心。也就是说，第一计算设备与第二计算设备和第一存储设备可以位于不同的数据中心，实现了第一文件系统的元数据在不同数据中心之间共享和流动，即，使得跨数据中心(跨域)的用户都可以明确第一文件系统的层次结构。

进一步的，跨数据中心(跨域的用户)可以基于元数据流(和/或第一文件系统的层次结构)，构建包含第一文件系统的层次结构的文件视图。

在第一方面的又一种可能的实施方式中，所述一个节点的标识和所述一个节点的父节点的标识共同作为一组记录的索引，该一组记录是同一个父目录下的同一个节点的记录。

其中，节点的标识是与节点一一对应的唯一标识，且不可更改。

通过节点的标识和节点的父节点的标识索引元数据流中的一组记录。一方面，使用节点的标识和父节点的标识可以指示节点的层次关系，便于确定节点的层次结构，而且能够移动节点的场景下能够基于索引来体现节点的父节点的变更。另一方面，由于节点的标识与节点一一对应且不可更改，因此，即便在节点的名称、大小、存放位置改变的情况下，依然可以通过索引找到节点对应的记录，提高了查找效率和结果准确性，进一步提升了元数据的稳定性和高可用性。

在第一方面的一种可能的实施方式中，所述节点的属性包含指示信息，所述指示信息用于指示对所述节点执行的变更操作。

其中，指示信息可以直接包含变更操作的名称，也可以通过标识、编号等间接指示变更操作。

可选的，变更操作可以包含新增(或创建)、更新、删除或移动等中的一项或者多项。

示例性地，指示信息可以通过字段的不同取值来描述。即，节点的属性中包含以下字段：对节点执行的变更操作。以字段名称为action字段为例，当action字段的值为create时，指示新增节点；当action字段的值为update时，指示更新节点。当然，字段的值与变更操作的对应关系、字段的名称、字段的顺序等，可以根据实际需求进行设置。

通过变更字段，可以记录节点变更，不仅可以提升元数据的准确性，且有利于实现元数据的共享和流动，进一步还有利于实现文件系统在多个设备上的视图更新。

在第一方面的一种可能的实施方式中，所述节点的属性包含与所述节点相关的事务的标识。示例性地，与所述节点相关的事务的标识可以通过字段的不同取值来描述。

其中，事务的标识可以用于指示某一次事务，从而可以将一次事务相关的多条记录进行关联，使得元数据具有了可以返回失效事务的能力，有利于保证在元数据共享和流动过程中文件系统的一致性。

在第一方面的一种可能的实施方式中，所述节点的属性包含所述记录的序列号。示例性地，记录的序列号可以通过字段的不同取值来描述。

通过序列号，可以支持队列消息的顺序和多方修改的排序，也便于系统实现数据完整性检测与恢复。

在第一方面的一种可能的实施方式中，所述节点的属性包含节点的存储布局信息。示例性地，记录的序列号可以通过字段的不同取值来描述。

这样一来，在节点的数据内容存储到多种设备的情况下，存储布局信息可以指示存储了节点的数据内容的设备信息，辅助其他设备从节点的实际存储设备获取数据内容。

在第一方面的一种可能的实施方式中，所述节点的属性包含所述节点的扩展属性。示例性地，所述节点的扩展属性可以通过字段的不同取值来描述。

扩展属性是根据不同的业务场景，对元数据进行扩展得到的属性。通过支持属性扩展，可以让用户根据实际使用需求定义节点新的属性，提高元数据的灵活性和可扩展性。

在第一方面的一种可能的实施方式中，所述节点的属性还包含名称(name)、类型(type)、权限(mode)、快照标识(snapid)、用户标识(uid)、用户组标识(gid)、大小(size)、软链接(linkto)、创建时间(ctime)、修改时间(mtime)、访问控制列表(acl)、扩展属性(attr)、等中的一项或者多项。

在第一方面的一种可能的实施方式中，所述方法还包括：

构建文件视图(便于区分称为文件视图V1)，该文件视图V1包含所述第一文件系统中的多个节点的层次结构。

通过文件视图，用户或应用可以方便地获取到节点的层次结构以及节点的属性，满足了对文件系统层级结构及节点的属性的可视化需求，提升了用户体验。

在第一方面的一种可能的实施方式中，所述方法还包括：

在所述第一元数据流的末端追加第一记录，所述第一记录中包含所述第一节点的标识，所述第一节点的父节点的标识和所述第一节点的第一属性，所述第一属性包括变更操作的类型。

其中，第一属性为了便于区分其他属性(其他记录中的属性、同一记录中的其他属性)所做出的示例性的描述，并不限定第一属性与其他属性的顺序、重要程度等的不同。

上述实施方式中，可以实现通过第一计算设备对第一文件系统进行变更，即，可以实现跨数据中心或跨域对第一文件系统进行变更。并且，对第一文件系统中的数据的变更操作可以以添加记录的方式追加到元数据流中，而其他设备通过获取元数据流的变化(追加的记录)，即可获知第一文件系统中发生的变更操作，相应的可以更新第一文件系统在本地的文件的层次结构或节点的属性，从而实现了文件视图在多个设备上的同步。

在一种可能的实施方式中，所述方法还包括：

获取第一输入输出(inputoutput，IO)请求，所述第一IO请求指示对第一节点执行变更操作。在这种方式中，对文件系统的变更通过元数据IO来实现，便于实现节点变更和上层应用之间的解耦，提升系统(包含文件系统和上层应用的系统)的灵活性和可扩展性。

在第一方面的一种可能的实施方式中，所述变更操作的类型为新增，所述第一节点是在所述第一文件系统中的新增的文件或目录。

在第一方面的一种可能的实施方式中，所述变更操作的类型为更新、删除或移动。此时，第一节点是所述第一文件系统中已经存在的文件或目录。

可选的，由于第一节点是第一文件系统中已经存在的文件或者目录，则第一元数据流中已经包含该第一文件对应的记录。

示例性的，第一元数据流中包含第二记录，所述第二记录包含所述第一节点的标识、所述第一节点的父节点的标识和所述第一节点的第二属性。所述第二记录产生于所述第一记录之前。

在第一方面的又一种可能的实施方式中，所述第一记录还包含所述第一记录的序列号，所述第二记录还包含所述第二记录的序列号，所述第一记录的序列号和所述第二记录的序列号用于指示所述第一记录产生在所述第二记录之后。

在第一方面的一种可能的实施方式中，所述方法还包括：

向所述第二计算设备发送消息，所述消息指示所述第一元数据流发生变化，以使得所述第二计算设备根据所述第一元数据流中的所述第一记录对所述第一节点执行所述变更操作。

在第一方面的一种可能的实施方式中，所述方法还包括：

在所述第一元数据流的末端出现新增加的记录的情况下，根据更新后的所述第一元数据流，更新文件视图(例如文件视图V1)，更新后的文件视图包含更新后的第一文件系统中的多个节点的层次结构。

在该实施方式中，第一计算设备在任何时候都可以根据第一元数据流的变化(新增加的记录)来获知第一文件系统中的变更，并据此更新第一文件系统的层次结构/文件属性，并更新文件视图。

在第一方面的一种可能的实施方式中，所述第一元数据流中包含第三记录，所述第三记录包含所述第一文件系统中的第二节点的属性，所述第二节点为文件，所述第二节点的属性包含所述第二节点的存储布局信息，所述第二节点的存储布局信息指示所述第一存储盘所属的存储设备；

所述方法还包括：

获取第二IO请求，所述第二IO请求指示读取所述第二节点的数据；

从所述第一存储盘获取所述第二节点的数据。

上述实施方式中，可以实现通过第一计算设备读取第一文件系统的数据，即，可以实现跨数据中心或跨域读取第一文件系统的数据。

在第一方面的一种可能的实施方式中，所述方法还包括：

对所述第一元数据流执行合并操作，所述合并操作指示对所述第一元数据流中的同一个节点对应的多条记录合并为一条记录。通过该实施方式，可以减小第一元数据流的占用空间，从而降低方案对存储的消耗。

在第一方面的一种可能的实施方式中，所述方法还包括：

获取第二文件系统的第二元数据流，所述第二文件系统的数据存储在第二存储盘，其中，所述第二元数据流来自与所述第二存储盘连接的所述第二计算设备，或来自与所述第二设备存储盘连接的第三计算设备，所述第二计算设备不同于所述第三计算设备；

所述第二元数据流为流式结构且包含多条记录，所述第二元数据流的多条记录中的每条记录包含所述第二文件系统中的一个节点的标识、所述第二文件系统中的所述一个节点的父节点的标识和所述第二文件系统中的所述一个节点的属性；

构建文件视图(便于区分称为文件视图V2)，所述文件视图V2包含所述第一文件系统中的多个节点的层次结构和所述第二文件系统中的多个节点的层次结构，所述第二文件系统中的多个节点的层次结构基于所述第二元数据流得到。

在该实施方式中，第一计算设备可以获取多个文件系统的元数据流，据此确定多个文件系统的层次结构，进而能够构建包括多个文件系统的层次结构的文件视图。

可选的，文件视图V2可以是更新文件视图V1所得到的文件视图。具体的，文件视图V1包含第一文件系统的多个节点的层次结构，而第一计算设备可以在文件视图V1中加入第二文件系统中的多个节点的结构层次，从而更新文件视图V1得到文件视图V2。在第一方面的一种可能的实施方式中，所述方法还包括：

扫描第三文件系统的多个节点的层次结构，所述第三文件系统的数据存储在与所述第一计算设备连接的第三存储盘上；

根据所述第三文件系统的多个节点的层次结构，构建第三元数据流，所述第三元数据流为流式结构且包含多条记录，所述多条记录中的每条记录包含所述第三文件系统中的一个节点的标识、所述第三文件系统中的所述一个节点的父节点的标识和所述第三文件系统中的所述一个节点的属性；

向所述第二计算设备发送所述第三元数据流，以使得所述第二计算设备根据所述第三元数据流确定所述第三文件系统中的多个节点的层次结构。

在该实施方式中，第一计算设备还可以基于本地的文件系统(第三文件系统，存储第三文件系统的存储设备与第一计算设备相连)构建第三元数据流，并将第三元数据流发送给其他计算设备，从而让其他计算设备上确定第三文件系统的层次结构，并进而可以让用户通过其他计算设备访问该第三文件系统的数据。

在第一方面的一种可能的实施方式中，所述第三文件系统中存在硬链接节点，所述根据所述第三文件系统的多个节点的层次结构，构建第三元数据流，包括：

根据所述第三文件系统的多个节点的层次结构和数据采集状态(ingestorstate)，构建第三元数据流，所述数据采集状态用于指示存在硬链接的节点以及存在硬链接的节点的父节点列表。

由于文件系统中的节点较多，逐一检查文件系统中的节点是否为硬链接节点需要耗费较多的计算能力和时间。因此，通过ingestor state来记录存在硬链接的节点以及存在硬链接的节点的父节点列表，可以节约构建数据流的时间并减少计算消耗，提升元数据流中的信息的准确性，提升用户在数据使用和管理上的便捷性。

在第一方面的一种可能的实施方式中，所述方法还包括：

构建文件视图(便于区分称为文件视图V3)，所述文件视图V3包括所述第三文件系统中的多个节点的层次结构。

可选的，该文件视图V3还可以包含所述第一文件系统中的多个节点的层次结构。进一步的，文件视图V3可以是更新文件视图V1所得到的更新后的文件视图。具体的，文件视图V1包含第一文件系统的多个节点的层次结构，而第一计算设备可以在文件视图V1中加入第三文件系统中的多个节点的结构层次，从而更新文件视图V1得到文件视图V3。

或者可选的，该文件视图V3可以包含所述第二文件系统中的多个节点的层次结构。进一步的，文件视图V3可以是更新文件视图V2所得到的更新后的文件视图。示例性的，文件视图V2包含第一文件系统的多个节点的层次结构和第二文件系统中多个节点的结构层次，而第一计算设备可以在文件视图V2中加入第三文件系统中的多个节点的结构层次，从而更新文件视图V2得到文件视图V3。在第一方面的一种可能的实施方式中，存储第一文件系统和第三文件系统的存储系统可以是异构的。

在第一方面的又一种可能的实施方式中，所述第一计算设备和所述第三存储盘包含于第一存储设备，所述第二计算设备和所述第一存储盘包含于第二存储设备，所述第一存储设备和所述第二存储设备是异构的存储设备。

在第一方面的一种可能的实施方式中，所述第一计算设备通过第一协议访问所述第三存储盘，第二计算设备通过第二协议访问所述第一存储盘，所述第一协议与所述第二协议不同。即，第一文件系统和第三文件系统可以异构的文件系统。

在第一方面的一种可能的实施方式中，所述第一数据流中包含第四记录，所述第四记录包含节点标识字段、父节点标识字段和所述第三节点的属性，其中，所述第四记录中的节点标识字段为第三节点的标识，所述第四记录中父节点标识字段为第四节点的标识，所述第四节点为目录；

所述方法还包括：

获取第三IO请求，所述第三IO请求指示在第五节点下创建所述第三节点的硬链接节点，所述第五节点为目录；

在所述第一元数据流的末端追加第五记录、第六记录和第七记录，其中：

所述第五记录包含节点标识字段、父节点标识字段和所述第三节点的属性，其中，所述第五记录中节点标识字段为所述第三节点的标识，所述第五记录中父节点标识字段为所述第三节点的标识；

所述第六记录包含节点标识字段和父节点标识字段，其中，所述第六记录中节点标识字段为所述第三节点的标识，所述第六记录中父节点标识字段为所述第四节点的标识；

所述第七记录包含节点标识字段和父节点标识字段，其中，所述第七记录中节点标识字段为所述第三节点的标识，所述第六记录中父节点标识字段为所述第五节点的标识。

可选的，节点标识字段为inode，父节点标识字段为pinode。在前述实施方式中，pinode的值通常为节点的父节点的标识，但是在创建硬链接的场景下，通过pinode与inode的值相同的方式来表示某一节点存在硬链接节点。

可以看出，元数据流可以兼容包含硬链接的文件系统，实现了以统一的方式来表达文件系统中硬链接节点的元数据，进一步提升了用户在数据使用和管理上的便捷性。

在第一方面的一种可能的实施方式中，所述方法还包括：

获取第四IO请求，所述第四IO请求指示删除所述在第五节点下的所述第三节点的硬链接节点；

在所述第一元数据流的末端追加第八记录，其中：

所述第八记录包含节点标识字段、父节点标识字段和所述第三节点的属性，其中，所述第八记录中节点标识字段为所述第三节点的标识，所述第八记录中父节点标识字段为所述第五节点的标识，所述第八记录中所述第三节点的属性包含指示删除操作的标识。

上述实施方式说明了在删除硬链接场景下元数据流的变更，通过在元数据流中追加记录的方式即可表示删除硬链接的操作，可以方便地实现某个文件系统的元数据在多个设备之间的互通和共享，极大地提升用户在数据使用和管理上的便捷性。

在第一方面的一种可能的实施方式中，所述方法还包括：

若不存在所述第三节点的硬链接节点，则在所述第一数据流的末端追加第九记录和第十记录；

所述第九记录中包含节点标识字段、父节点标识字段和所述第三节点的属性，所述第九记录中节点标识字段为所述第三节点的标识，所述第九记录中父节点标识字段为所述第四节点的标识；

所述第十记录中包含节点标识字段、父节点标识字段和所述第三节点的属性，所述第十记录中节点标识字段为所述第三节点的标识，所述第十记录中父节点标识字段为所述第三节点的标识，所述第十记录中的所述第三节点的属性包含指示删除操作的标识。

上述实施方式说明了将存在硬链接的节点恢复为普通节点(区别存在硬链接的节点)的场景下元数据流的变更，通过在元数据流中追加记录的方式即可表示将存在硬链接的节点恢复为普通节点，从而可以方便地实现某个文件系统的元数据在多个设备之间的互通和共享，进一步提升用户在数据使用和管理上的便捷性。

第二方面，本身实施例提供一种元数据共享系统，该元数据共享系统包含第一计算设备和第二计算设备，所述第二计算设备与第一存储盘相连，所述第一存储盘上存储第一文件系统的数据；所述第一计算设备用于实现前述第一方面任一项所描述的方法。

在第二方面的一种可能的实施方式中，所述第二计算设备，用于：

扫描第一文件系统的多个节点的层次结构；

根据所述第一文件系统的多个节点的层次结构，构建第一元数据流，所述第一元数据流为流式结构且包含多条记录，每条记录包含所述第一文件系统中的一个节点的标识、所述第一文件系统中的所述一个节点的父节点的标识和所述第一文件系统中的所述一个节点的属性；

向所述第一计算设备发送所述第一数据流；

所述第一计算设备，用于：

获取来自所述第二计算设备的第一数据流；

在第二方面的一种可能的实施方式中，所述第一计算设备，还用于构建文件视图(便于区分称为文件视图V1)，所述文件视图V1包含所述第一文件系统中的多个节点的层次结构。

在第二方面的一种可能的实施方式中，所述第二计算设备还用于构建文件视图(便于区分称为文件视图V4)，所述文件视图V4包含所述第一文件系统中的多个节点的层次结构。

在第二方面的一种可能的实施方式中，所述第一计算设备，还用于：

获取第一输入输出IO请求，所述第一IO请求指示对第一节点执行变更操作；

在所述第一元数据流的末端追加第一记录，所述第一记录中包含所述第一节点的inode，所述第一节点的pinode，和变更后的所述第一节点的第一属性，所述变更后的所述第一节点的第一属性包括所述变更操作的类型；

所述第二计算设备，还用于：

获取所述第一元数据流中的所述第一记录；

根据所述第一元数据流中的所述第一记录对所述第一节点执行变更操作。

向所述第二计算设备发送消息，所述消息指示所述第一元数据流发生变化；

所述第二计算设备，还用于：

获取所述消息。

在所述第一元数据流的末端出现新增加的记录的情况下，根据更新后的所述第一元数据流，更新文件视图，更新后的文件视图包含更新后的所述第一文件系统中的多个节点的层次结构；

所述第二计算设备，还用于：

在所述第一元数据流的末端出现新增加的记录的情况下，根据更新后的所述第一元数据流，更新文件视图V4，更新的文件视图V4包含更新后的所述第一文件系统中的多个节点的层次结构。

在第二方面的一种可能的实施方式中，所述元数据流中包含第二记录，所述第二记录包含所述第二文件系统中的第二节点的属性，所述第二节点为文件；

所述第二节点的属性包含所述第二节点的存储布局信息，所述第二节点的存储布局信息指示所述第一存储盘所属的存储设备；

所述第一计算设备还用于，还用于：

从所述第一存储盘获取所述第二节点的数据。

在第二方面的一种可能的实施方式中，所述方法还包括：

将所述第二节点的数据内容响应给所述第二IO请求。

对所述第一元数据流执行合并操作，所述合并操作指示对所述第一元数据流中的同一个节点对应的多条记录合并为一条记录。

在第二方面的一种可能的实施方式中，所述第二计算设备，还用于：

在第二方面的一种可能的实施方式中，所述元数据共享系统还包含第三计算设备，所述第三计算设备，用于：

向所述第一计算设备发送第二文件系统的第二元数据流，所述第二文件系统的数据存储在与所述第三计算设备连接的第二存储盘上，

所述第一计算设备，还用于：

获取所述第二元数据流，

可选的，该文件视图V2可以是更新文件视图V1得到的，或者更新文件视图V3得到的。

扫描第三文件系统的多个节点的层次结构，所述第三文件系统的数据存储在第三存储盘上，所述第一计算设备与所述第三存储盘相连；

根据所述第三文件系统的多个节点的层次结构，构建第三元数据流；

向所述第二计算设备发送所述第三元数据流；

所述第二计算设备，还用于：

获取来自所述第一计算设备的第三数据流；

根据所述第三元数据流，确定所述第三文件系统中的多个节点的层次结构。

在第二方面的一种可能的实施方式中，所述第一计算设备还用于：

构建文件视图(便于区分称为文件视图V3)，所述文件视图V3包含所述第一文件系统的结构层次和所述第三文件系统的结构层次。

可选的，该文件视图V3可以是更新文件视图V2或更新文件系统V2得到的。

在第二方面的一种可能的实施方式中，所述第二计算设备还用于：

构建文件视图(便于区分称为文件视图V5)，所述文件视图V5包括第一文件系统中的多个节点的层次结构和所述第三文件系统中的多个节点的层次结构。

可选的，该文件视图V5可以是更新文件视图V4得到的。

在第二方面的一种可能的实施方式中，

所述第二计算设备和所述第一存储盘包含于第一存储设备，所述第一计算设备和所述第三存储盘包含于第二存储设备，所述第一存储设备和所述第二存储设备是异构的。

在第二方面的一种可能的实施方式中，所述第一文件系统通过第一访问协议被主机访问，所述第三文件系统通过第二访问协议被主机访问，所述第一访问协议与所述第二访问协议不同。

第三方面，本申请实施例提供一种计算装置，所述计算装置包含通信模块和处理模块，所述计算装置用于实现第一方面任一项所描述的方法。

在第三方面的一种可能的实施方式中，所述通信模块，用于获取第一文件系统的第一元数据流，所述第一元数据流来自第二计算设备，所述第一元数据流为流式结构且包含多条记录，每条记录包含所述第一文件系统中的一个节点的标识、所述第一文件系统中的一个节点的父节点的标识和所述第一文件系统中的一个节点的属性；

所述处理模块，还用于根据所述第一元数据流，确定所述第一文件系统中的多个节点的层次结构。

在第三方面的又一种可能的实施方式中，所述处理模块，还用于：

在第三方面的又一种可能的实施方式中，所述处理模块和所述通信模块，还用于：

在第三方面的又一种可能的实施方式中，所述通信模块，还用于：

获取第一输入输出(inputoutput，IO)请求，所述第一IO请求指示对第一节点执行变更操作。

在第三方面的又一种可能的实施方式中，所述通信模块和所述处理模块，还用于：

获取第二IO请求，所述第二IO请求指示读取第二节点的数据，所述第二节点属于所述第一文件系统；

从所述第一存储盘获取所述第二节点的数据。

在第三方面的又一种可能的实施方式中，所述第一元数据流中包含第三记录，所述第三记录包含所述第一文件系统中的第二节点的属性，所述第二节点为文件，所述第二节点的属性包含所述第二节点的存储布局信息，所述第二节点的存储布局信息指示所述第一存储盘所属的存储设备。

所述处理模块，还用于构建文件视图(便于区分称为文件视图V2)，所述文件视图V2包含所述第一文件系统中的多个节点的层次结构和所述第二文件系统中的多个节点的层次结构，所述第二文件系统中的多个节点的层次结构基于所述第二元数据流得到。

所述通信模块，还用于：

在第三方面的又一种可能的实施方式中，所述第三文件系统中存在硬链接节点，所述处理模块，还用于：

在第三方面的又一种可能的实施方式中，所述第一数据流中包含第四记录，所述第四记录包含节点标识字段、父节点标识字段和所述第三节点的属性，其中，所述第四记录中的节点标识字段为第三节点的标识，所述第四记录中父节点标识字段为第四节点的标识，所述第四节点为目录。所述通信模块，还用于：

在所述第一元数据流的末端追加第八记录，其中：

第四方面，本申请实施例提供一种节点的元数据(其中，节点为文件系统中的文件或目录)，所述节点的元数据包含所述节点的标识、所述节点的父节点标识和所述节点的属性，其中，所述节点的属性包含以下字段中的一项或者多项：

对所述节点执行的变更操作、与所述节点相关的事务的标识、所述节点的元数据的序列号、所述节点的存储布局信息、所述节点的扩展属性。

第五方面，本申请实施例提供一种文件系统的元数据流，所述元数据流为流式结构且包含多条记录，所述多条记录中的每条记录包含所述文件系统中的一个节点的标识、所述一个节点的父节点的标识和所述一个节点的属性，所述一个节点为一个文件或一个目录。

其中，流式结构是包含多条记录的一种数据结构，每一条记录包含多个值，每一个值对应了一个字段，流式结构具有以下特征：只读、只增、有序，其中“只读”是指流式结构中的记录的值只能读取而无法修改；“只增”指示流式结构中只能追加新的记录而无法删除已有的记录，但属于同一个节点的多条记录可以被合并成一条记录；“有序”是指流式结构中的记录具有逻辑顺序，追加的记录在流式结构的尾部增加。

在第五方面的又一种可能的实施方式中，所述一个节点的标识和所述一个节点的父节点的标识共同作为一组记录的索引，该一组记录是同一个父目录下的同一个节点的记录。

在第五方面的又一种可能的实施方式中，所述节点的属性包含以下字段中的一项或者多项：

在第五方面的又一种可能的实施方式中，所述元数据流被多个设备共享，当某一设备在元数据流末端追加新的记录时，共享元数据流的多个设备可以从元数据流中读取新增加的记录，从而获取文件系统的变更，实现文件系统的变更同步。

在第五方面的又一种可能的实施方式中，元数据流中包含基线(checkpoint)和CDC流。

在checkpoint中，一个节点只对应一条记录。即，checkpoint中每条记录的索引是唯一的。

CDC流是在checkpoint的基础上追加记录得到的。

第五方面的又一种可能的实施方式中，元数据流可以被合并，合并操作可以将同一个节点对应的多条记录合并为一条记录。

第六方面，本申请实施例提供一种计算设备，该计算设备包括处理器和存储器；所述处理器用于执行存储器中存储的指令，以使得所述计算设备实现前述第一方面任一项所描述的方法。

可选的，所述计算设备还包括通信接口，所述通信接口用于接收和/或发送数据，和/或，所述通信接口用于为所述处理器提供输入和/或输出。

需要说明的是，上述实施例是以通过调用计算机指定来执行方法的处理器(或称通用处理器)为例进行说明。具体实施过程中，处理器还可以是专用处理器，此时计算机指令已经预先加载在处理器中。可选的，处理器还可以既包括专用处理器也包括通用处理器。

可选的，处理器和存储器还可能集成于一个器件中，即处理器和存储器还可以被集成在一起。

第七方面，本申请实施例还提供一种计算设备集群，该计算设备集群包含至少一个计算设备，每个计算设备包括处理器和存储器；

所述至少一个计算设备的处理器用于执行所述至少一个计算设备的存储器中存储的指令，以使得所述计算设备集群执行第一方面任一项所述的方法。

第八方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在至少一个处理器上运行时，实现前述第一方面任一项所描述的方法。

第九方面，本申请提供了一种计算机程序产品，计算机程序产品包括计算机指令，当所述指令在至少一个处理器上运行时，实现前述第一方面任一项所描述的方法。

可选的，该计算机程序产品可以为一个软件安装包或镜像包，在需要使用前述方法的情况下，可以下载该计算机程序产品并在计算设备上执行该计算机程序产品。

本申请第二至第九方面所提供的技术方案，其有益效果可以参考第一方面的技术方案的有益效果，此处不再赘述。

附图说明

下面将对实施例描述中所需要使用的附图作简单地介绍。

图1是本申请实施例提供的一种包含多个节点的文件系统的示意图；

图2是本申请实施例提供的一种元数据结构的示意图；

图3是本申请实施例提供的一种元数据格式的示意图；

图4是本申请实施例提供的一种文件变更及元数据变更的场景示意图；

图5是本申请实施例提供的一种元数据流的示意图；

图6A是本申请实施例提供的一种记录的示意图；

图6B是本申请实施例提供的又一种记录的示意图；

图6C是本申请实施例提供的又两种记录的示意图；

图6D是本申请实施例提供的一种记录的示意图；

图7是本申请实施例提供的又一种元数据流的示意图；

图8是本申请实施例提供的又一种元数据流的示意图；

图9是本申请实施例提供的一种元数据共享系统的架构示意图；

图10是本申请实施例提供的又一种元数据共享系统的架构示意图；

图11是本申请实施例提供的一种元数据共享系统的运行场景示意图；

图12是本申请实施例提供的又一种元数据共享系统的运行场景示意图；

图13是本申请实施例提供的一种数据处理方法的流程示意图；

图14是本申请实施例提供的一种文件系统的结构层次和元数据流的示意图；

图15是本申请实施例提供的又一种数据处理方法的流程示意图；

图16是本申请实施例提供的又一种数据处理方法的流程示意图；

图17A是本申请实施例提供的一种包含硬链接的文件系统的inode的示意图；

图17B是本申请实施例提供的一种文件系统的视图；

图17C是本申请实施例提供的一种元数据流的示意图；

图18A是本申请实施例提供的一种创建硬链接前的文件系统及其元数据流的示意图；

图18B是本申请实施例提供的一种创建硬链接后的文件系统及其元数据流的示意图；

图18C是本申请实施例提供的又一种创建硬链接后的文件系统及其元数据流的示意图；

图19A是本申请实施例提供的一种删除硬链接节点后的文件系统及其元数据流的示意图；

图19B是本申请实施例提供的一种删除硬链接节点后的文件系统及其元数据流的示意图；

图20是本申请实施例提供的一种计算装置的结构示意图；

图21是本申请实施例提供的一种计算设备的结构示意图。

具体实施方式

下面结合附图对本申请实施例进行详细介绍。

为了便于理解，以下示例地给出了部分与本申请实施例相关概念的说明以供参考。如下所示：

1.文件系统：文件系统是用于明确存储盘(例如磁盘、固态硬盘、或分区等)上的文件的方法和数据结构，即在存储盘上组织文件的方法。文件系统的主要作用是让用户可以便捷地读写文件，例如，用户向文件系统提供指定文件的标识(例如文件的名称、文件的路径等),文件系统即可就可以存取对应文件的数据。

对文件的读写通过文件系统的访问协议来完成。根据文件的读写服务的所使用的访问协议不同，文件系统可以包含以下类型的文件系统：网络文件系统(network filesystem，NFS)、基于服务器信息块(server message block，SMB)协议的文件系统、通用Internet文件系统(common internet file system、CIFS)、简单存储服务(simplestorage service，S3)、Hadoop分布式文件系统(Hadoop distributed file system，HDFS)、对象存储服务(object storage service，OBS)等。

应理解，本申请所涉及的文件系统是指具有树形层次结构的、为多个文件提供存取、访问服务的系统。一些场景中，具备类似特征的系统其名称可能不一定称为文件系统，但本申请实施例统一称为文件系统。

例如，一些对象系统在存储对象时，多个对象之间也具有树形层次结构，则也落入本申请实施例中“文件系统”的范围。可选的，文件系统中存储的文件，其数据内容一般为非结构化的数据，例如文档、图片、视频、音频等没有固定结构的数据。

2.节点(node)、inode：本申请实施例使用节点来表示文件系统中的文件和/或目录。即，一个节点可能是一个文件，或者是一个目录。当存在多个节点时，多个节点可能全部是文件，也可能全部是目录，或者部分是文件、部分是目录。

如图1所示是本申请实施例提供的一种包含多个节点的文件系统的示意图，这多个节点包含多个文件和多个目录。在图1中，为了方便理解将目录使用方框(为了便于区别，根目录为菱形)图案来示意，文件使用圆形图案来示意。当然，这并不旨在说明文件和目录在存储方式、呈现方式上的不同。另外，节点的编号、节点排列顺序、节点的名称等仅为示例，并不旨在限定本申请。

不同的节点通过节点的标识来进行区分，一个节点的标识是唯一的。应理解，这里的不同的节点是指在物理上、具有不同的数据内容的节点。在一些场景中，不同目录下的不同节点名指向存储盘上的相同的数据内容，则应该看作同一个节点(例如硬链接、软链接等场景下)。

在一些可能的场景中，节点的数据内容存储在存储盘中，而文件系统还需要找到一个地方存储节点的元信息。作为一种可能的方案，节点的元信息存储在inode中。inode是一种数据结构，包含了与节点相关的一些信息，例如节点的数据内容的位置(如数据块block的位置)、节点的字节数、节点的权限(例如读权限、写权限、执行权限等)、节点的时间戳(例如创建时间、上一次变动的时间、或上一次打开的时间等)、链接数(即有多少个节点的名字指向这个inode)等中的一项或者多项。

在这种情况下，节点的标识可以为inode的标识，例如inode的编号(inodenumber)、索引节点的索引(inodeindex)等。

需要说明的是，由于节点的标识可以唯一对应一个inode，本领域技术人员通常直接用inode代指节点的标识。在本申请的部分实施例也使用inode来表示节点的标识。

一些场景中，inode用于存储节点的元数据。一些可能的设计中，inode是节点的基础元数据格式，基于inode，计算设备可以得到其他格式或满足特定用户需求的元数据。

3.文件、数据、元数据：文件，或称计算机文件，是一个信息集合。文件包含数据和元数据。数据即文件的数据内容；元数据即描述文件的信息，例如文件的名称、文件的大小、文件的类型等。

如图1所示的文件系统包含名称为“001.png”的文件、名称为“002.png”的文件等。而文件的元数据描述了文件的名称、类型、大小、位置、创建人、创建时间、或权限等。应理解，此处的文件的元数据是一种示例性的元数据。

可选的，该元数据可以为文件系统私有格式的元数据。例如，一种Linux系统中使用Ext4文件系统，其具有适用于Ext4文件系统的元数据格式。

4.目录：为了便于对文件进行存取和管理，需建立文件名与物理地址的映射关系，体现这种映射关系的数据结构称为目录，或称为文件目录。

5.异构的文件系统：

异构是指具有不同访问(和/或控制)方式或具有不同的元数据格式的文件系统。通常来说，不同类型的文件系统是通常异构的文件系统，不同的供应商提供的文件系统也通常为异构的文件系统。

与异构相反的描述是同构，同构的文件系统之间可以通过统一的元数据管理和数据访问控制来实现全局数据访问系统。

6.事务

事务是指一个操作序列，这些操作要么全部执行、要么全部不执行，是一个不可分割的工作单位。例如，将文件从目录1移动到目录2，包含两个操作：在目录1删除文件和在目录2新增文件。这两个操作是关联且不可分割的，在目录1下删除文件也必须保证在目录2下新增了文件。如果这两个操作中任意一个操作没有成功执行，这两个操作都应该取消、回滚，避免当操作的中间环节出现问题时，产生数据不一致的问题。

7.变更数据获取(Change Data Capture，CDC)：监测并捕获数据的变更(包括数据的新增、更新、或删除等)，将这些变更按发生的顺序完整记录下来，写入到消息中间件中以供其他服务进行订阅及消费。

8.消息队列

消息队列是一种数据结构，可以理解为包含一条或者多条消息的列表。消息在被处理和删除之前存储在消息队列上，消息发送方通过消息队列服务可以与消息接收方进行交互。应理解，本申请为了便于描述，故将包含多个消息的数据结构统一称为消息队列，并不旨在限定通过队列的方式实现消息队列。例如，具体实施过程中，消息队列还可以通过列表、堆、链表、或栈等方式来实现。

9.硬链接：指不同的节点名链接同一个数据内容的现象。

以节点的元信息通过inode来存储的情况为例，即文件系统有两个目录(便于区分称为目录A和目录B)及两个节点(便于区分称为节点file1和节点file2)，节点file1的父目录为文件夹A，节点file1的inode为1；节点file2的父目录为文件夹B，节点file2的inode也为1。由于节点的数据内容，由节点的inode中指向的存储位置来确定，因此当不同节点名指向同一个inode时，该不同的节点名也指向同一个数据内容，则文件file1和节点file2可以称为硬链接节点。

上述对概念的介绍可以使用在以下的实施例中。

随着用户业务规模的增长和对服务的要求的提升，业务应用通常需要部署多个文件系统，这些文件系统很有可能是异构的，这使得存储在异构的文件系统中的数据变成了数据的孤岛，为用户的数据使用和管理带来极大的不便。

例如，用户的业务数据以NFS类型的文件系统的形式部署在A地的数据中心，而用户的计算设备位于B地，且该计算设备不支持读取NFS类型的文件系统的元数据。则用户无法通过B地的计算设备访问存储在A地的文件系统，使得用户的访问受到阻碍。

即便用户可以通过数据传输(例如，通过远程复制等)读取NFS类型的文件系统的元数据，由于NFS的元数据通常是静态的，无法表现文件系统的变更。当A地的文件系统中的文件系统变更时，如何将变更高效地同步给B地的计算设备也成为一个难题。

总之，元数据在各种异构的文件系统中按照各自不同的方式进行管理和控制，使得文件系统的元数据无法高效共享与流动。

有鉴于此，本申请实施例提供一种元数据结构、元数据流的结构、数据处理方法以及相关装置，实现了以统一的方式来表达异构文件系统的元数据，该统一的表达方式能够屏蔽异构文件系统之间元数据管理和访问控制方式的差异，也能屏蔽存储异构文件系统的设备之间的差异。即，通过本申请中统一的流式结构的元数据表达方式，能够拉通异构文件系统之间的元数据，从而使得异构的文件系统中的数据不再是一个个数据孤岛，这会极大地提升用户在数据使用和管理上的便捷性。并且，由于本申请中统一表达文件元数据的方式是流式结构，该流式结构的“只读”、“只增”和“有序”的特性可以反映出文件系统中的各种变更操作，即本申请中流式结构的元数据的表达方式可以动态地反映文件系统的变化。

下面先对本申请实施例中提供的元数据的格式进行介绍。

请参见图2，图2是本申请实施例提供的一种元数据结构的示意图。元数据包含节点的标识和节点的父节点的标识以及节点的属性。

其中，节点的标识是用于区分不同节点的标识。例如，节点的标识包含但不限于是节点的ID、节点的编号、节点的数据所存放的数据块的位置等。

在一些可能的场景中，节点与inode一一对应，而节点标识可以为节点的inode的标识，也称为inode number，本文中直接使用inode来指代inode number。如图1所述，根目录的节点的标识为0；文件名称为“苹果”的文件，节点的标识为1；文件名称为“照片1”的文件，节点的标识为60。其余节点的标识，以此类推此处不再一一说明。

节点的父节点的标识可以用于唯一确定该节点的父节点。通过节点的标识和父节点的标识可以确定该节点和该节点的父节点，从而确定多个节点之间的层次结构。

在一些可能的方案中，节点的标识是节点对应的inode，因此，节点的父节点的标识即节点的父节点对应的inode，部分实施例中表示为pinode。

例如，pinode字段的值可以指示节点的父节点的标识。如图1所示，节点60(节点的标识为60的节点)的父节点的标识为1，可以表示为：节点60的pinode字段的值为1。

当然，一些场景中(例如硬链接等场景中)，pinode的值可能有其他设计(在下文中描述)。

节点的属性包含描述节点的信息。示例性的，节点的属性包含以下信息中的一项或者多项：名称(name)、类型(type)、模式(mode)、快照标识(snapid)、用户标识(uid)、用户组标识(gid)、大小(size)、变更操作(action)、事务标识(tid)、软链接(linkto)、创建时间(ctime)、修改时间(mtime)、最后访问时间(accesstime，atime)、序列号(sn)、数据信息(datainfo)、标准扩展属性、额外扩展属性、访问控制列表(acl)等中的一项或者多项。下面对其中部分信息进行示例性地介绍：

其中，type用于指示节点的类型，节点的类型例如为文件、目录、硬链接等中的一项或者多项。文件是具有具体数据内容的节点，例如文本文档、图片、或程序等。文件通常具有文件扩展名，用于指示文件格式(例如，图片文件常常以JPEG格式保存并且文件扩展名为.jpg)。目录，一些场景下可以理解为文件夹，是一种用来写协助管理文件的数据结构。一些场景中，每一个目录对应一块磁盘空间。

节点的类型可以通过字段的值来指示。例如，当type字段取值为FILE时指示节点为文件；当type字段取值为FOLDER时指示目录。再如，当type字段取值为0时指示节点为文件；当type字段取值为1时指示目录；当type字段取值为2时指示硬链接。

mode用于指示文件的权限信息，也称为权限位。其取值通常与节点的读取权限、写入权限、或分享权限相关。

snapid用于指示文件系统快照的标识。uid为节点拥有者的id。gid为节点所属组的id。size用于指示节点的大小，例如为比特数、字节数等。

变更操作(action)指示对节点的变更操作的类型，其可以指示以下类型中的一项或者多项：增加(create)、更新(update)、修改(modify)、或删除(delete)等。变更操作可以记录节点经过了何种变更，从而使得元数据可以表现节点的动态变化，满足用户对于动态变化的元数据的需求，有利于实现元数据的共享和流动，提升文件系统的服务质量。

例如，设备A可以向设备B共享文件系统的元数据，以在设备B上呈现文件系统的视图。当设备A对文件系统中的节点进行变更时，元数据流中新增的节点的元数据记录中可以包括该节点的变更操作的类型。该新增的元数据记录可以被共享给设备B，在设备B上触发对文件系统的视图的更新，使得设备B的用户或者设备B上的业务应用可以查看更加准确的文件系统的视图(可以反映变更后的文件系统的内容)。

可以看出，通过变更操作字段，可以记录文件变更相关信息，不仅可以提升元数据的准确性，且有利于实现元数据的共享和流动，进一步还有利于实现共享文件系统在多个设备上的视图更新。

事务标识(tid)指示了在文件系统中执行的若干个事务，该若干个事务与文件系统中的节点相关，包含但不限于是移动节点、批量创建节点、批量删除节点或批量修改节点名等事务。以移动文件为例，该事务包含在源目录下删除文件和在新目录下创建文件两个操作，这两个操作要么都执行成功，要么都执行失败，是不可分割的单位。

通过事务标识，可以将多条元数据关联到具体某一个事务；当需要回滚事务时，可以将一个事务所关联的元数据的变更都撤销。总之，事务标识可以实现对多条元数据之间的关联，使得元数据具有了可以返回失效事务的能力，有利于保证在元数据共享和流动过程中文件系统的一致性。

序列号(serial number，sn)用于指示该条元数据的序列号，可选取值为携带所述元数据的消息的序列号。

通过序列号可以便于实现排序、检查元数据遗漏，有利于实现元数据的共享和流动。在一些场景中，序列号字段能够用于支持CDC消息、修改排序以及数据的数据完整性检测与恢复。

数据信息(datainfo)用于指示节点的存储布局信息，有利于数据的获取。例如，节点的数据可以同时布局到多种存储设备，和/或，支持多种存储布局格式，此时，需要获取数据的设备根据节点的存储布局信息，从存储数据的存储设备上取到节点的数据内容。

可选的，数据信息中可以包含存储布局信息(devicedatamap)，存储布局信息中包含存储该节点的数据的设备ID(deviceID)、数据位图(例如，blockbitmap)、地址(address)。

进一步可选的，地址包含项目标识(objectid)、数据的起始位置(offset)、数据的长度(length)等。

标准扩展属性(部分实施例中表示为xattr)包含一个或者多个属性。一些可能的设计中，标准扩展属性包含文件访问协议中预先定义的扩展属性。应理解，标准扩展属性可以用于兼容现有文件系统的元数据中定义的扩展属性。例如，NFS中定义了部分扩展属性，则标准扩展属性可以兼容NFS所定义的扩展属性。

额外扩展属性(部分实施例中表示为tags)包含一个或者多个属性。一些可能的设计中，额外扩展属性包含用户根据需求定义的一个或者多个扩展属性。例如，在现有文件系统定义的扩展属性之外，额外定义的一个或者多个的扩展属性，提高元数据的适用性和可扩展性。可选的，额外扩展属性的格式为键值(Key-Value，KV)数组。可选该KV数组的长度为可变长的，以支持属性扩展。

通过扩展属性，如标准扩展属性、额外扩展属性，既满足了用户对于元数据的可扩展性需求，也可以控制元数据结构的层级，有利于对元数据进行管理。

访问控制列表(accesscontrollist，ACL)用于记录节点的访问控制权限。可选的，控制访问列表中可以包含一个或者多个接入控制项，例如接入控制1、接入控制2等。在接入控制项中，可以包含接入控制类型(type)、标志位(flag)、许可(permission)、规则(principal)、受托者(trustee)、继承来源(inherited_from)、适用者(apply_to)等信息中的一项或者多项。

以上对元数据中部分数据进行了示例性地介绍，应理解，上述介绍是为了便于理解而进行的示例性的说明，不应理解为对元数据格式的限定。一些场景中，对于部分属性的含义、使用方式、层级关系，也可以参照现有技术中的说明。

示例性地，上述属性的数据类型可以为整型(int)、浮点型(float)，数组(byte_array)、组(group)等。

上述属性可以通过字段的形式来存储或传输。为了便于理解，图3示出了本申请实施例提供的一种元数据格式的示意图。

其中，元数据称为文件元数据信息(massagefile_meta)，其包含字段的信息，例如字段是否必须(非必须的字段前标识可选，即optional)、字段的数据类型、字段的长度等。如图3所示，形如“int64 pinode”的字符，指：字段的值为64位(或最长为64位)的整型，字段名称为“pinode”。再如，形如“optionalint32 type”的字符，指：该字段为可选字段，字段的值为32位(或最长为32位)的整型，字段名称为type。其余情况以此类推，此处不再一一示意。

应理解，本申请部分实施例中使用inode字段和pinode字段来示例性地分别表示节点的标识和节点的父节点的标识，并不旨在限定节点的标识只能通过inode表示，一些场景中也可以使用其他的方式起来表示节点的标识和节点的父节点的标识。另外，本申请所说明的字段名称是为了方便理解给出的示例性的名称，并不作为对文件的属性的限定，描述文件的属性的字段，其名称可以有不同于图1、图3的其他设计，本申请对此不做严格限定。

节点的信息由元数据来描述。由于文件系统会随时变更，此时，文件系统中的节点对应的元数据也会相应地变更以便于准确地描述节点。其中，文件系统的变更包含但不限于是增加节点、删除节点、更新(或称修改)节点或移动节点等。

以下以文件为例，对节点的变更进行说明，对于目录的情况也同样适用。图4所示是本申请实施例提供的一种文件变更及元数据变更的场景示意图。如图4所示，在某一时刻，文件系统(其标识为F1)中被创建了名称为“001.png”的文件，该文件具有对应的元数据(便于区分称为元数据M1)。如图4所示，该文件的inode为60，pinode的标识为59。进一步的，元数据M1中包含文件的属性，以描述文件的名称、类型、大小等。

可选的，元数据M1中包含变更操作字段，变更操作字段的值指示了新增(create)操作。

若文件被执行变更操作，则文件的元数据也应当相应变更。示例性的，名称为“001.png”的文件更名为“003.png”，此时元数据M1中的名称也相应变更，得到新的元数据M2。如图4所示，元数据M2中，文件的名称已变更。进一步的，元数据M2中包含变更操作字段，变更操作字段的值指示修改(modify)操作或指示更新(update)操作。

可以看出，节点的变更可以由元数据的变更来表示。文件系统中的节点在多个时期的元数据，需要通过一种数据结构来统一存储。

本申请实施例提供一种元数据流，该元数据流为包含多条记录的流式结构，可以记录文件系统的元数据变化，并可以反映文件系统中的数据的变更，通过该流式结构的元数据的表达方式，可以实现元数据的流动和共享。

在元数据流中，记录可以看作是文件在某个时期的一条元数据，也称为元数据记录。记录所包含的信息与节点的元数据的属性相同，或者部分属性相同(例如一些场景中对元数据进行处理后得到记录，处理过程中可能改变了元数据的属性名称、属性层级、或增删了部分属性等)。

而流式结构是一种以流的形式来表示数据的数据结构。流式结构具有以下特征：只读、只增、有序，其中“只读”是指流式结构中的记录的值能够被读取而无法被修改；“只增”指示流式结构中只能追加新的记录而无法删除已有的记录，但属于同一个节点的记录可以被合并成一条记录；“有序”是指流式结构中的记录具有逻辑顺序，当需要增加新的记录时，新的记录在流式结构的末端追加。进一步的，当需要追加多个新的记录时，多个记录按照变更的时间进行排序(例如，通过各个记录中的序列号来反映各记录发生的先后顺序)。

如图5所示是本申请实施例提供的一种元数据流的示意图，该元数据流为第一文件系统的元数据。应理解，本申请实施例的第一文件系统是指某一个(或某一组)具体的文件系统，并不旨在限定文件系统的类型。例如，该第一文件系统为标识为F1的文件系统。另外，某一组文件系统可以理解为包含多个文件系统的文件系统集合。例如，一些技术中通过私有协议将跨地域的多个文件系统连成全局文件系统，以满足用户任意位置访问数据的需求，这样的全局文件系统可以看做一个文件系统集合，即一组文件系统。当然，文件系统集合依然有其对应的标识，以索引该文件系统集合。

元数据流包含多条记录，每条记录对应了一个节点，该节点属于第一文件系统。记录包含节点的标识和节点的父节点的标识，可选包含名称(name)、类型(type)、权限(mode)、快照标识(snapid)、用户标识(uid)、用户组标识(gid)、大小(size)、变更操作(action)、事务标识(tid)、软链接(linkto)、创建时间(ctime)、修改时间(mtime)、访问时间(atime)、序列号(sn)、数据信息(datainfo)、访问控制列表(acl)、标准扩展属性(attr)、扩展属性(tags)等中的一项或者多项(图5中示出部分字段)。

可选的，元数据流中记录的部分字段为可选字段，即：记录中部分字段对应的值可以空缺、或者为默认值、或者参考其他记录的属性等。

作为一种可能的设计，元数据流被多个设备共享，当某一设备在元数据流末端追加新的记录时，共享元数据流的多个设备可以从元数据流中读取新增加的记录，从而获取文件系统中的变更，实现文件系统的变更同步。由于元数据流中可以不断增加记录，因此，元数据流可以实现元数据的流动和共享，有利于实现文件系统的视图在多个设备上的同步。

以上对于元数据流的基本结构进行了介绍，下面对元数据流的一些可能设计进行说明。应理解，下面的多种设计可以单独实施，也可以进行组合实施，对于多种设计组合实施的情况本申请实施例不再赘述。

【设计1】

作为一种可能的设计，节点的父节点的标识(例如表示为pinode)和节点的标识(例如表示为inode)共同作为一组记录的索引，该一组记录是同一个父目录下的同一个节点的记录。一些场景中，记录的索引也称为记录的键或记录的唯一主键(unique key)。

示例性的，若记录S1的pinode和记录S2的pinode相同，且记录S1的inode和记录S2的inode也相同，则记录S1和记录S2属于同一组记录。

由于节点名称可能会产生变更，而节点的标识通常是固定的，因此将节点的标识作为索引的一部分，可以延长索引的时效。另外，由于节点可能会在多个目录下移动，因此，通过节点的父节点的标识和节点的目录标识可以定位某一节点以及确定多个节点的层次结构，而且在移动了节点的场景下能够基于索引来体现节点的父节点的变更。相应的，将节点的父节点的标识和节点的标识作为索引，可以方便查找到指定节点对应的记录，而且适用于节点名称变更的场景，在纵向回溯节点的生命周期的场景下，能够提高查找效率和结果准确性，提高了元数据的稳定性和高可用性。

【设计2】

作为又一种可能的设计，文件系统的元数据流可以被提供给多个设备(在多个设备间共享)。当元数据流中追加了新的记录时，共享元数据流的多个设备能够获取元数据流中新增的记录，从而根据新增的记录更新文件系统的相关信息，例如文件系统的层级结构、文件系统的视图或文件系统中节点的属性等。

例如，文件系统部署在设备A上，而该文件系统的元数据流可以在设备A、设备B和设备C之间共享、同步，使得在设备A、设备B、设备C可以构建包含该文件系统的节点之间层次结构的文件视图。

当设备B对该文件系统中的某个节点(文件或目录)执行了变更操作，设备B可以在元数据流中追加新的记录。设备A、设备B和设备C可以从元数据流中获取追加的记录，以更新该文件系统的相关信息(更新文件系统的层次结构等)，从而实现文件系统的元数据在多个设备之间的动态同步。

另外，在这种设计中多个共享元数据流的设备之间则无需相互感知，例如，设备A在元数据流中追加新的记录后，设备B和设备C通过共享的元数据流即可获取新的记录，有利于实现多设备系统(指包含多个设备的系统)的松耦合协作，提高系统的灵活性和可扩展性。

【设计3】

在前述实施方式中，节点的变更可以通过记录中的action字段的值来指示。当然，具体实施过程中，节点的变更也可以通过其他方式指示。

作为又一种可能的设计，节点的变更通过元数据流中的一条或者多条记录来指示。为了便于理解，以下示例性的说明指示变更操作的可能实现方式：

实现方式一：对于某一记录，若该记录的索引在之前的元数据流(该记录之前的元数据流)中不存在，表示新建(create，或称为新增)节点。

例如，图6A所示为本申请实施例提供的一种记录的示意图，该记录被追加到如图5所示的元数据流。该记录的unique key为：“pinode：500，inode：987”，其他相关信息的描述可以参见前述图2所示的实施例。由于图5所示的元数据流中不存在该unique key，则表示该记录对应的节点是新创建的节点。

实现方式二：对于某一记录，若该记录的索引在之前的元数据流中存在，表示更新(update)节点，或表示修改(modify)节点。

示例性的，如图5所示的区域501中的记录，其unique key为：“pinode为59，inode为60”，在之前的元数据流已经存在该unique key(如区域403所示)，则表示对该节点的修改。结合记录中的其他属性，可以确定节点60的名称由“001.png”变更为“003.png”。

如图6B所示为本申请实施例提供的又一种记录的示意图。示例性的，若变更操作为：将节点987的权限修改为0755，并设置扩展属性用户名(user_name)，其值为“Michelle”，则追加的记录如图6B所示。

作为一种可能的实施方式，在修改节点时，记录中包含节点的inode和更新的属性，可选包含操作类型的指示信息和/或序列号。例如，图5所示的记录包含权限字段和扩展属性字段，action字段为UPDATE(或MODIFY)，扩展属性字段为：{[“name”:“user_name”,“value”:“Michelle”]}。

可选的，在修改节点的情况下，记录中可以不包含未被更新的属性。当然，具体实施过程中也可以包含pinode以及未更新的属性等。

实现方式三：对于两条记录，若两条记录的inode相同但pinode不同，且一条记录包含删除标记，则表示节点的移动。

如图6C所示为本申请实施例提供的又两种记录的示意图。示例性的，将节点987从节点500移动到节点400下，则追加的记录如图6C所示。其中，记录601表示在节点400下新增节点，记录601中包含节点987的inode和pinode，可选包含节点名、指示更新操作的信息、事务标识和序列号等；类似的，记录602表示删除节点500下的节点987，记录602中包含节点987的inode、pinode和删除标记，可选包含节点名、删除标记、事务标识、或序列号等。

应理解，节点移动是一个事务，因此执行该事务所追加的记录具有相同的事务标识，即，记录601中的事务标识与记录602中的事务标识相同。

实现方式四：对于某一记录，若该记录中包含删除标记，则表示删除该记录对应的节点。例如，删除标记可以通过更新操作(action)字段来指示，当action字段为delete时，表示删除节点。

如图6D所示为本申请实施例提供的又一种记录的示意图。示例性的，若变更操作为：删除节点987，则追加的记录如图6D所示。如图6D所示的记录包含节点987的inode和删除标记。可选包含pinode、sn或其他节点的属性等。

可选的，在节点包含硬链接节点的情况下，指示删除节点的记录中包含节点的pinode。

应理解，图6A到图6D是为了方便理解而列举的一种JSON格式的元数据，不作为对元数据流中记录的格式限定。

实现方式五：对于某一记录，若该记录的inode的值和pinode的值相同，表示节点上创建了硬链接(下文中进行描述)。

上述的几种情况是为了方便理解元数据流中记录的含义而列举的几种可能的情况，具体实施过程中可以包含更多或者更少的情况，或者部分变更也可以通过其他方式来表示。

【设计4】

作为一种可能的实施方式，元数据流中可以包含基线(checkpoint)和CDC流。

其中，checkpoint也可以称为基础静态元数据。在checkpoint中，一个节点只对应一条记录。即，checkpoint中每条记录的索引是唯一的。

CDC流也称为动态文件系统操作数据，是在checkpoint的基础上追加记录所得到的一条(或者多条)流式结构的数据，即：CDC流的中记录的追加时间通常在checkpoint流之后。

另外，在CDC流中，记录的索引不一定唯一，可能存在一个节点对应多条记录。即：可能存在两条或两条以上的记录具有相同的索引。这是因为，当文件系统中发生的每个变更，都会在CDC流中追加一条或多条记录，而文件系统中的一个节点可能发生多次变更，相应地，CDC流中会追加与该节点对应的多条记录。

例如，图5中的元数据流中示出了checkpoint和CDC流，区域502和区域503所示的记录包含于checkpoint；而区域501中的记录是在checkpoint之后追加的记录，属于CDC流。

作为一种可能的方案，checkpoint是有边界的流，CDC流是无边界的流。换句话说，checkpoint中记录的数量有限制(与节点数量、节点是否存在硬链接等相关)，而CDC流中，记录的数量可以不限制。例如，一些场景中的CDC中的记录数量与生成checkpoint时文件系统中节点的数量一致；而由于一个节点可能会被多次更新，因此CDC流中一个节点对应的记录数量无边界。

【设计5】

作为一种可能的实施方式，元数据流可以被合并。执行合并操作的主体可以为共享元数据流的多个设备中的一个设备，也可以是部署了第一文件系统的设备，或者是提供元数据服务的设备，或者是指定的元数据流的管理设备。

具体的，设备对元数据流执行合并操作，将第一元数据流中的同一个节点对应的多条记录合并为一条记录。

如图7所示为本申请实施例提供的又一种元数据流的示意图，图7所示的新的checkpoint的示意图，是设备对图5所示的元数据流执行合并操作，将CDC流中的记录合并到checkpoint中得到的。在图5中，checkpoint包含节点60对应的记录，CDC中也包含节点60的记录；在合并后，节点60对应的多条记录被合并为一条，其属性为最新的属性，如区域701所示。

在这种实施方式中，元数据流中的CDC流可以被合并，从而得到精简版本的元数据流，减少了元数据流中记录的数量，不仅节约了存储空间，也可以提升后续的接入设备读取元数据流的效率和处理流的效率，提升用户体验。

可选的，在不同的时期对元数据流进行合并，可以得到文件系统不同时期的checkpoint，例如，多个checkpoint可以通过标识(例如编号、ID或名称)来区分，例如checkpoint0、checkpoint1等。

在生成新的checkpoint时，旧的checkpoint也可以保留。通过不同的时期的多个checkpoint可以在文件系统回滚或者版本回溯时提供支持，从而提高文件系统的故障回复能力，提升文件系统的鲁棒性。

【设计6】

作为一种可能的方式，checkpoint以压缩文件的格式进行存储。示例性地，存储checkpoint的文件，其文件格式包含但不限于是列存储格式(例如parquet、Carbondata)、或行存储格式(例如Avro)等。

如图8所示为本申请实施例提供的又一种元数据流的示意图。可选的，checkpoint在存储时可以划分为多个数据块进行存储，即：每一个数据块被压缩为一个(或一组)压缩文件。

如图8所示，文件系统F1对应的checkpoint(checkpoint的编号为10)包含89个元数据块(即Meta)，分别编号从0至88。其中，“F1/Meta/0”指示编号为0的Meta中存储的记录，F1为文件系统的标识；“F1/Meta/5”指示编号为5的Meta中存储的记录；“F1/Meta/88”指示编号为88的Meta中存储的记录，其余未示出的记录可以参考前述，此处不再一一说明。

可选的，Meta的划分可以与节点的层级关系、分支关系、记录的条数、记录的顺序或记录的数据大小等中的一项或者多项相关。例如，在划分Meta时，控制Meta的大小(或字节数)小于或者小于等于第一阈值，该第一阈值例如为10M、20M等。可选的，第一阈值可以是用户、厂商、相关机构组织(例如标准机构)、管理设备等预先定义或者预先配置的。

作为一种可能的实施方式，CDC流可以通过消息队列的形式进行存储，以提高CDC流的实时性。例如，消息队列中包含多个消息，每个消息中包含一条记录。共享元数据流的设备通过读取消息队列中的消息，从而可以获取CDC中的记录。

可选的，CDC流中的记录可以存储为Log形式。例如，CDC流划分为若干个Log。

进一步的，Log可能有多个(多个可能是同时存在，也可能存在于不同的时期)，多个Log之间具有时间上的先后顺序，多个Log之间可以通过标识(例如ID、编号等)进行区分，如图8所示的“F1/meta/log/10”表名编号为10的Log。

作为一种可能的方案，前述对数据流执行合并操作时，具体可以为：将Log中的记录合并到Meta中。

可选的，元数据流的相关信息中包含Log基点(Log base)信息，通过Log base可以记录当前checkpoint合并的Log的标识，以使得共享数据流的设备在读取CDC流时，可以读取在Log base之后的Log，从而避免读取重复的数据，提升元数据流的读取效率以及读取的结果准确性。

上面对本申请实施例的元数据结构和元数据流结构进行了介绍，下面对本申请实施例系统架构进行示例性地描述。

需要说明的是，本申请描述的系统架构是为了更加清楚的说明本申请的技术方案，并不构成对于本申请提供的技术方案的限定，本领域普通技术人员可知，随着系统架构的演变和新业务场景的出现，本申请提供的技术方案对于类似的技术问题，同样适用。

请参见图9，图9是本申请实施例提供的一种元数据共享系统的架构示意图，该元数据共享系统90包含第一计算设备901和第二计算设备902。元数据共享系统90中的设备之间的元数据共享通过元数据流903来实现。

其中：

元数据流903是第一文件系统的元数据流，第一文件系统为某一个(或某一组)具体的文件系统。例如，元数据流903与第一文件系统的标识之间存在对应关系，如图5所示的元数据为标识为F1的文件系统的元数据流。其中，元数据流903为流式结构且包含多条记录，每条记录包含节点的inode、pinode和节点的属性，相关描述可以参考前文。

第一计算设备901具有数据处理能力和通信能力，能够完成以下一种或者多种操作：构建第一元数据流、获取第一元数据流、在元数据流中追加新的记录、或读取元数据流中新追加的记录等。

应理解，本申请实施例中的计算设备(例如第一计算设备901、第二计算设备902)可以包含硬件、软件模块、或者软件和硬件结合的装置等。可选的，计算设备可以通过硬件实体实现，也可以通过虚拟化技术来实现。示例性的，计算设备可以为控制器、处理器、服务器、虚拟机、云端等。其中，控制器包含但不限于存储控制器(例如内存控制器、硬盘控制器、集成驱动器，电子控制器、磁盘阵列控制器等)、组合逻辑控制器、硬布线控制器等。处理器包含但不限于是中央处理器、图片处理器、人工智能处理器、微处理器或可编程逻辑门阵列等，另外，在一些场景中，因控制器也具有计算能力和/或能够执行指令，因此控制器也可以看作处理器。服务器包含但不限于是通用计算机、存储服务器、云服务器或刀片式服务器等。当计算设备的功能由服务器实现时，其所包含的服务器的数量也可以是一个，也可以是多个(如服务器集群)。虚拟机是被虚拟化的计算模块。云端是采用应用程序虚拟化技术的软件平台，能够让一个或者多个软件、应用在独立的虚拟化环境中开发、运行。可选的，云端可以部署在公有云、私有云、或者混合云上等。

第二计算设备902具有数据处理能力和通信能力，能够完成以下一种或者多种操作：构建第一元数据流、获取第一元数据流、在元数据流中追加新的记录、或读取元数据流中新追加的记录等。

本申请实施例中，将第一文件系统的元数据以统一表达方式(元数据流903)在多个计算设备之间的共享流动，使得多个计算设备都可以方便地获取第一文件系统的元数据并基于元数据流903确定第一文件系统的层次结构，从而实现某个文件系统的元数据在多个设备之间的互通和共享，极大地提升了用户在数据使用和管理上的便捷性。

示例性的，元数据流903可以是由第二计算设备902构建的。第一计算设备901可以获取该元数据流903，并基于该元数据流903确定第一文件系统的层次结构，并可以基于此构建第一文件系统的文件视图。也就是说，该元数据共享系统实现了第一文件系统的元数据在第一计算设备901和第二计算设备902之间的共享和流动，使得用户通过第一计算设备901和第二计算设备902都可以明确第一文件系统的层次结构(并可以基于此进一步明确包含第一文件系统的层次结构的文件视图)，提升了用户的使用体验。

可选的，元数据共享系统90还可以包含存储盘904，第一文件系统的数据可以存储在存储盘904中，第二计算设备902与存储盘904之间具有通信连接。

其中，第二计算设备902与存储盘904可以是独立的，或者，集成的。

作为一种可能的实施方式，第二计算设备902和存储盘904可以包含于同一个设备，例如存储设备、或存储系统中。以二者包含存储设备中为例，第二计算设备902可以是存储设备上的控制器，存储盘904可以是存储设备中的存储介质，二者可以通过总线或网络实现通信连接。网络例如为有线网络、无线网络、有线网络和无线网络的组合等。例如，二者通过网线连接，或者，通过交换机连接。作为又一种可能的方式，第二计算设备902和存储盘904属于不同的存储设备(或存储系统)。例如，存储盘904包含于存储设备中，第二计算设备902在存储设备之外的、独立的计算设备，二者通过相连。

示例性的，存储盘904可以为硬盘，第二计算设备902为硬盘控制器，该硬盘控制器用于管理前述的硬盘。

可选的，元数据共享系统90还包含存储盘905，第一计算设备901与存储盘905相连。类似的，第一计算设备901与存储盘905可以是独立的，或者，集成的，相关描述可以参考前述对第一计算设备901和存储盘905之间的描述。

可选的，第一计算设备901和存储盘905属于第二存储设备，第一计算设备901和存储盘905属于第一存储设备，第一存储设备和第二存储设备是异构的存储设备。例如，第一存储设备属于A厂商提供的分布式存储系统，第二存储设备属于A厂商提供的对象存储系统。再如，第一存储设备属于A厂商提供的分布式存储系统，第二存储设备属于B厂商提供的分部署存储系统。

作为一种可能的实施方式，存储盘905中存储有文件系统的数据(便于区分称为第三文件系统，例如，第三文件系统为标识为F3的文件系统)。

该第三文件系统和前述的第一文件系统中的访问(和/或控制)方式不同，和/或，二者具有不同的元数据格式。

在一种可能的实施方式中，第一计算设备901和第二计算设备902可以位于不同的数据中心。示例性的，上述第一计算设备位于第一数据中心，第二计算设备位于第二数据中心。这种实施方式中，通过元数据流，实现了第一文件系统的元数据在不同数据中心之间共享和流动，即，使得跨数据中心的用户都可以明确第一文件系统的层次结构。进一步的，跨数据中心可以基于元数据流(和/或第一文件系统的层次结构)，构建包含第一文件系统的层次结构的文件视图。

可选的，在第二计算设备902与存储盘904相连的情况下，存储盘904与第二计算设备902可以位于同一个数据中心，例如二者均位于第二数据中心。

类似的，在第一计算设备901与存储盘905相连的情况下，存储盘905与第一计算设备901可以位于同一个数据中心，例如二者均位于第一数据中心。

在一种可能的实施方式中，第一计算设备901和第二计算设备902可以位于不同的地域。例如，第一计算设备901位于A市，而第二计算设备902位于B市。即，上述实施方式可以使得跨域的用户都可以明确第一文件系统的层次结构，并进一步使得跨域的计算设备可以构建包含第一文件系统的层次结构的文件视图。

在一些可能的场景中，外部设备可以向存储盘或存储盘所在的存储设备(或存储系统)发起IO请求，以访问存储盘中的文件系统的数据(数据IO请求)、或对文件系统执行变更(元数据IO请求)。而计算设备可以感知外部设备发起的IO请求，并响应该IO请求执行相关操作。这里的外部设备是指在存储盘之外的设备，或存储所在的存储设备之外的设备，例如主机、服务器、或公有云等，本申请对此不做限定。为了便于说明，以下以外部设备是主机为例进行示例性的介绍。

图10所示是本申请实施例提供的又一种元数据共享系统的架构示意图，元数据共享系统100包含存储设备1001、存储设备1002、元数据流1003和主机，其中：

存储设备1001包含第一控制器1004和存储盘905，第一控制器1004和存储盘905相连。关于第一控制器1004的相关描述可以参考前述第一计算设备901，存储盘905的相关描述参考前述。

存储设备1002包含第二控制器1005和存储盘904，第二控制器1005和存储盘904相连。关于第二控制器1005的相关描述可以参考前述第二计算设备902，存储盘904的相关描述参考前述。

元数据流1003是第一文件系统的元数据流，第一文件系统例如为文件系统F1和/或文件系统F2。存储设备1001和存储设备1002可以获取该元数据流1003，并基于此明确第一文件系统的层次结构，进一步呈现第一文件系统的视图。

主机(本文中指生产主机)是面向用户的设备，或者，运行业务应用的设备，能够发起IO请求。可选的，主机可以与存储设备(包含存储盘)相连或者与计算设备(与存储盘连接)相连，使得用户或业务应用可以发起针对存储盘中存储的数据的IO请求。

作为一种可能的实施方式，主机1006与存储设备1001相连，此时主机1006可以向存储设备1001发起IO请求。例如，主机1006可以请求读取文件系统F1的数据、读取文件系统F3的数据、请求对文件系统F1执行变更、或请求对文件系统F3行变更等。

可理解的，由于存储设备1001和存储设备1002通过元数据流1003可以实现文件系统F3的元数据的共享和流动，使得存储设备1001可以确定文件系统F3的层次结构(并可以基于此进一步明确包含第一文件系统的层次结构的文件视图)，因此，主机1006可以请求读取文件系统F3的数据和/或请求对文件系统F2执行变更。

类似的，主机1007与存储设备1002相连，此时主机1007可以向存储设备1002发起IO请求。例如，主机1007可以请求读取文件系统F1的数据、读取文件系统F2的数据、请求对文件系统F1执行变更、或请求对文件系统F2行变更等。

以上图10是以存储盘和计算设备集成的情况进行介绍，对存储盘和计算设备独立设置的情况，可以有其他实现方式使得计算设备获取主机对存储盘中的数据访问(各种IO请求)。例如，以下示例性列举两种可能的实现方式：

实现方式1，计算设备能够明确第一文件系统的层次结构，第一文件系统为文件系统F1和/或文件系统F3等。计算设备与主机相连，主机针对第一文件系统的IO请求先到达计算设备，再由计算设备IO进行处理。

例如，以图9为例，当第一计算设备901接收到主机的IO请求，该IO请求指示读取文件系统F2中某文件的数据时，由于第一计算设备901与存储盘905相连，则第一计算设备可以从存储盘905读取该文件的数据，反馈给主机。

再如，以如9为例，当第一计算设备901接收到主机的IO请求，该IO请求指示在文件系统F1中增加某节点时，第一计算设备901可以在元数据流903中追加记录。

实现方式2，存储盘包含于存储设备中，计算设备是独立与存储设备之外的设备，且计算设备和存储设备相连接。此时，主机与存储设备相连，主机的IO请求先到达存储设备，计算设备从存储设备中(例如存储设备的控制器中)获取主机的IO请求。

可选的，该IO请求可以是计算设备向存储设备主动请求，或，存储设备可以主动向计算设备反馈IO。

应理解，上述两种实现方式还可以进行结合。另外，具体实施过程中还可能有其他实现方式使得主机的IO被处理，此处不再一一说明。

作为一种可能的实施方式，文件系统F1通过第一访问协议被主机访问，文件系统F3通过第二访问协议被主机访问，第一访问协议和第二访问协议不同。

上面已经介绍了元数据共享系统的系统架构，下面示例性地提供几种元数据共享系统的运行场景以便于理解。

请参见图11，图11是本申请实施例提供的一种元数据共享系统的运行场景示意图。如下图所示，文件系统F3的数据存储在第一计算设备连接的存储盘上。第一计算设备(可以看作生产者)可以共享出文件系统F3的元数据流，第二计算设备(可以看作消费者)和第三计算设备(可以看作消费者)根据该元数据流在本地构建与第一计算设备相同的文件视图。

进一步的，第一计算设备、第二计算设备和第三计算设备对文件系统的变更，可以以记录的形式写入元数据流。相应的，第一计算设备、第二计算设备和第三计算设备可以读取元数据流以保持多方元数据的同步，并基于元数据流获取文件系统的变更以便于文件系统视图的更新。

在一些可能的场景中，在元数据流中写入记录或者从元数据流中读取记录需要具备相应的权限。

作为一种可能的实施方式，第一计算设备、第二计算设备和/或第三计算设备，可以接收主机的IO请求，并响应该IO请求执行相关操作。

例如，第二计算设备可以接收主机针对文件系统F3中某一文件的数据内容的IO请求，第二计算设备从存储该文件系统F3的数据的存储盘上获取该文件的数据内容。

作为一种可能的设计，元数据共享系统中建立了数据和控制通道(如图11所示)，用于传输数据、命令、指令或消息等中的一项或者多项。在这种情况下，文件的数据内容的请求和反馈可以基于数据和控制通道来实现。

以上图11对一个设备向多个设备共享元数据流的情况进行了描述，以下对设备接收多个元数据流的场景进行介绍。

请参见图12，图12是本申请实施例提供的又一种可能的元数据共享系统的运行场景示意图，元数据共享系统包含存储设备S1、存储设备S2和存储设备S3。其中，存储设备S1、存储设备S2和存储设备S3中包含控制器和存储盘，相关描述可以参考前述。应理解，图12是以计算设备(即控制器)和存储盘集成在存储设备的情况为例进行介绍，对于二者使用其他方式连接的情况本申请同样适用。

其中，存储设备S1上存储了文件系统F1的数据，存储设备S2上存储了文件系统F2的数据。可选的，文件系统F1和文件系统F2的种类可以不同，即：存储设备S1和存储设备S2可以是异构的。例如，存储设备S1上的文件系统为一种HDFS，存储设备S2上的文件系统为一种NFS。

作为一种可能的实现，存储设备S1、存储设备S2可以共享自身存储的文件系统的元数据流，存储设备S3可以基于存储设备S1、存储设备S2共享的元数据流得到联合文件系统(基于多个文件系统联合得到的文件系统，也称全局文件系统)的视图，联合文件系统的视图中包含存储设备S1上的文件系统的视图和存储设备S2上的文件系统的视图。

如图12所示，存储设备S1中存在文件系统F1，其视图如区域1201所示；存储设备S2上的文件系统F2的视图如区域1202所示。示例性的，在文件系统F1的视图中，节点名称为“S1”表示文件系统F1中的根目录；节点名称为“2022-01-01”的节点、节点名称为“2022-04-08”的节点等为前述根目录下的示例节点；其中，节点名称为“001.data”的节点、节点名称为“008.data”的节点等为节点名称为“2022-04-08”的节点下的示例性节点。文件系统F2的视图可以参考前述文件系统F1的视图。

存储设备S3得到的联合文件系统的视图如区域1203所示，其中包含前述文件系统F1的层次结构和文件系统F2的层次结构。

在一种可能的设计中，不同的文件系统的元数据流独立设置。如图12所示，存储设备S1共享文件系统F1的元数据流，存储设备S3可以获取文件系统F1的元数据流。类似的，存储设备S2共享文件系统F2的元数据流，存储设备S3可以获取文件系统F2的元数据流。存储设备S3基于文件系统F1的元数据流和文件系统F2的元数据流，得到联合文件系统的视图。

在一种可能的设计中，不同的文件系统的元数据流也可以集成在一起。可选的，元数据流的记录中包含文件系统的标识以区分不同文件系统的元数据流。

可选的，如图12所示的元数据共享系统中还包含数据管理系统1204。数据管理系统1204能够对联合文件系统中的数据进行管理，比如用于实现数据查询、数据画像、数据使用监控等。

进一步可选的，如图12所示的元数据共享系统中还可以连接一种或者多种服务(图12未示出)，包含但不限于是数据服务(例如数据迁移、数据备份等)、消息队列服务、全局元数据服务、全局数据服务、数据调度服务或元数据分析服务等中的一项或者多项。当然，服务还可以是租户自定义的服务、或软件等。

应理解，图12所示的元数据共享系统中，不同主体之间的通信所使用的通信线路可以包含物理链路、数据链路、或总线等中的一项或者多项。

作为一种可能的设计，图12所示的元数据共享系统的通信可以由总线来实现，总线可以为硬件，或者软件，或者为硬件和软件的组合。示例性，总线1205为虚拟总线。

下面对本申请实施例的方法进行详细介绍。

请参见图13，图13是本申请实施例提供的一种数据处理方法的流程示意图。可选的，该方法可以应用于前述的元数据共享系统，例如图9、图10、图11、或图12等实施方式所描述的元数据共享系统。

如图13所示的数据处理方法可以包括步骤S1301至步骤S1304中的一个或者多个步骤。应理解，本申请为了方便描述，故通过S1301至S1304这一顺序进行描述，并不旨在限定一定通过上述顺序进行执行。本申请实施例对于上述一个或多个步骤的执行的先后顺序、执行的时间、执行的次数等不做限定。

步骤S1301至步骤S1304具体如下：

步骤S1301：第二计算设备根据第一文件系统中的多个节点的层次结构，构建第一元数据流。

其中，第二计算设备是具有计算能力的设备。例如第二计算设备可以包含控制器、处理器、虚拟计算实例等装置，其中虚拟计算实例可以为虚拟机、或容器等。再如第二计算设备可以包含服务器、主机等设备。

第一文件系统是指某一个或者某一组文件系统。例如，第一文件系统指标识为指定标识的文件系统。其中，文件系统的标识可以包含文件系统的身份标识(identification，ID)、编号或名称等。

可选的，第一文件系统的数据可以存储于与第二计算设备相连接的第一存储盘上。

第一文件系统中包含多个节点，多个节点中的任一个节点都以孩子的形式连接到父节点下，形成树形结构，根节点为根目录。文件系统的层次结构中包含父节点和/或父节点下的一个或者多个节点。

第一元数据流为流式结构且包含多条记录，每条记录包含第一文件系统中的一个节点的标识(例如inode)、所述节点的父节点的标识(例如pinode)和所述节点的属性。关于第一元数据流的结构的相关描述可以参考图5、图7和图8的相关描述，此处不再一一说明。

作为一种可能的实施方式，层次结构中包含文件系统的逻辑关系，例如节点与节点之间的父子关系、节点与节点之间的兄弟关系或不同子树的关系等。在构建元数据流时，第二计算设备根据第一文件系统的逻辑关系，构建第一文件系统的元数据流。

一些场景中，元数据流是部分有序的。

作为一种可能的实施方式，元数据流中，父节点对应的记录先于父节点下的孩子节点的记录。如图14所示是本申请实施例提供的一种文件系统的结构层次和元数据流的示意图，文件系统的层次结构如图14的(a)部分所示，反映了多个节点中的父节点、孩子节点、叶子节点等。在文件系统的层次结构中，根目录(inode为0)下的两个节点分别为节点1(即inode为“1”的节点)、节点2(即inode为“2”的节点)，节点1的孩子节点为节点60(即inode为“60”的文件)和节点61(即inode为“61”的文件)。如图14的(b)部分，在元数据流中，节点1对应的记录(如区域1401所示)先于节点60对应的记录(如区域1402所示)和节点61对应的记录(如区域1403所示)。

可选的，兄弟节点对应的记录在元数据流中的顺序有多种可能情况。

例如，父节点下的左孩子节点对应的记录先于右孩子节点对应的记录。如图14的(b)部分所示，节点1的对应的记录先于节点2对应的记录。

再如，父目录下的右孩子节点对应的记录先于左孩子节点对应的记录。如图14的(c)部分所示，节点2的对应的记录先于节点1对应的记录。

在一些可能的设计中，不同的子树的文件的记录之间可以不限定记录的先后顺序。

例如，左子树中的节点对应的记录，先于右子树中的节点对应的记录。如图14的(b)部分所示，节点1的对应的记录、节点60对应的记录和节点61对应的记录均先于节点2对应的记录。

再如，右子树中的节点对应的记录先于左子树中的节点的对应的记录。

在一些可能的设计中，节点的兄弟节点对应的记录先于节点的孩子节点对应的记录。如图14的(d)部分所示，节点2对应的记录先于节点60对应的记录和节点61对应的记录。

作为一种可能的实施方式，第一计算设备扫描可以扫描第一文件系统的层次结构，从而确定第一文件系统中多个节点的结构层次。

作为一种又可能的实施方式，第一文件系统存在私有格式的元数据，该私有格式的元数据流记录了第一文件系统的层次结构。第一计算可以扫描文件系统的私有格式的元数据，并对私有格式的元数据进行处理，得到第一文件系统的元数据流。其中，对私有格式的元数据进行处理，可以包含表格化处理、流化处理等，生成可以追加到元数据流中的记录。

步骤S1302：第二计算设备共享第一元数据流。

作为一种可能的实施方式，第二计算设备可以通过全局元数据流服务共享第一元数据流。其中，全局元数据服务用于管理第一元数据流并实现第一元数据流在多个设备之间的同步。第二计算设备可以向全局元数据流服务中推送第一元数据流，共享该第一元数据流的设备可以从全局元数据流中获取该第一元数据流。

作为又一种可能的实施方式，第二计算设备可以向其他设备(例如第一计算设备)发送所述第一元数据流。应理解，这里发送的方式可以是直接发送，也可以是间接发送。对于间接发送方式，第二计算设备可以将第一元数据流发送到共享设备(例如共享存储池、中间存储设备等)，其他设备可以从共享设备获取该第一元数据流。

可选的，在第二计算设备共享第一元数据流后，第一元数据流中还可以被追加记录。例如，第二计算设备对第一文件系统执行了变更操作，此时可以在元数据流中追加记录，以共享第一元数据流的多个设备之间同步对文件系统的更新。当然，其他设备也可以在第一元数据流中追加记录。

作为一种可能的实施方式，第一元数据流可以包含checkpoint和CDC流。进一步的，追加的记录被增加在CDC流的末端。关于checkpoint和CDC流的相关描述可以参考前述图4所示实施例中的描述，此处不再赘述。

步骤S1303：第一计算设备获取第一元数据流。

其中，第一计算设备属于共享第一元数据流的多个设备之一，从而可以获取第一元数据流。可选的，第一计算设备可以是从全局元数据服务获取第一元数据流。或者可选的，第一计算设备可以接收第二计算设备发送的第一元数据流。

可选的，第一计算设备获取的元数据流，可以是第二计算设备构建的第一元数据流，此时第一元数据流中还未追加新的记录。

或者，第一计算设备获取的元数据流，可以是经过追加记录的元数据流。例如，第一元数据流包含checkpoint和CDC流，CDC流中包含由于文件系统的变更所追加的记录。

步骤S1304：第一计算设备根据第一元数据流，确定第一文件系统中多个节点的层次结构。

由于元数据流中的记录包含节点的标识和节点的父节点的标识。对于任一节点，第一计算设备可以基于节点和父节点确定节点之间的拓扑关系，从而得到多个节点的层次结构。以图14的(b)部分所示，第一计算设备基于区域1401所示的记录，可以确定节点1的父节点为根目录；类似的，基于区域1402所示的记录，可以确定为节点60的父节点为节点1，其余情况以此类推，从而得到多个节点的层次机构。

作为一种可能的实施方式，第一计算设备可以构建文件视图，文件视图包含所述第一文件系统的层次结构。可选的，文件视图还可以包含节点的相关信息，例如节点的名称、节点的类型等。

可选的，文件视图的呈现可能有多种实现方式。例如，文件视图可以通过树形结构呈现，例如图11所示的文件系统F1的文件视图。再如，文件视图可以通过文件夹、或节点目录的形式呈现，例如图12中区域1203、区域1201、区域1201所示的文件视图。

通过文件视图，业务应用或用户可以直观地获取第一文件系统的层次结构，并按需对第一文件系统中的节点执行变更操作，和/或，按需访问文件系统中的节点。

下面先对节点变更的相关情况进行介绍。

在使用文件系统时，用户或者业务应用经常需要对文件系统进行变更。例如，用户在第一文件系统的视图中，通过点击、长按、双击、选中等界面操作，在文件系统中新增节点、修改节点的属性、移动节点或删除节点等。再如，管理员或者数据调度引擎、数据管理系统等，按需对文件系统中的节点进行迁移、分级、数据备份等，这些过程中都会涉及对文件系统中的节点的变更。

可选的，用户或者业务应用对文件系统的变更，可以通过发起输入输出(inputoutput，IO)请求来实现。例如，第一计算设备构建的文件视图，可以提供给主机并在主机连接的显示设备上呈现，主机的用户可以呈现文件视图的界面上，执行界面操作以发起IO请求。再如，业务应用调用接口，以发起IO请求。

作为一种可能的实施方式，第一计算设备获取第一IO请求，该第一IO请求指示对第一文件执行变更操作。变更操作可以包含新增、修改、移动或删除等中的一项或者多项。

示例性地，所述变更操作的类型为新增，此时，第一节点是在所述第一文件系统中的新增的节点。

示例性地，所述变更操作的类型为更新、删除或移动等。在这种情况下，第一节点是第一文件系统中已经存在的节点。可选的，由于第一节点是第一文件系统中已经存在的文件或者目录，则第一元数据流中已经包含该第一文件对应的记录。示例性的，第一元数据流中包含第一节点对应的记录(便于描述以下称为第二记录)，第二记录包含第一节点的标识、第一节点的父节点的标识和第一节点的属性。可理解的，第二记录可以是一条记录，也可以是多条记录。例如，第一节点在之前已经经历过修改，此时元数据流中可能包含第一节点对应的多条记录。

第一IO请求指示对第一文件执行变更操作，而第一计算设备需要将该变更操作同步给其它设备。一方面，其他设备需要根据变更操作来个更新第一文件系统的层次结构(或文件视图)，另一方面，存储第一文件系统的设备需要基于变更操作更新本地的文件系统(和/或私有格式的元数据)。

作为一种可能的实施方式，第一计算设备对文件系统的变更通过共享的第一元数据流同步给其他设备。以下以节点的标识为inode，节点的父节点的标识为pinode为例进行描述。

示例性的，第一计算设备在第一元数据流的末端追加关于第一节点的记录(便于区分称为第一记录)，该第一记录中包含所述第一节点的inode、所述第一节点的pinode和变更后的所述第一节点的属性(便于区分称为第一属性)。可选的，第一属性包括变更操作的类型。其它设备(例如第二计算设备)通过读取第一元数据流(或者读取元数据流中新增加的记录)，即可获取第一计算设备对文件系统的变更，实现文件系统的层次结构(或视图)在多个设备上的更新。

而第一元数据流的变更，可以通过如下两种方式告知共享元数据流的设备：

方式一，维护第一元数据流的设备或者服务，可以向共享第一元数据流的设备(或者某些指定设备)发送消息，以指示第一元数据流中存在新增的记录。可选的，在第一元数据流由设备来维护的情况下，维护第一元数据流的设备可以为第一计算设备、第二计算设备或其他具有存储空间和计算能力的设备。在第一元数据流通过服务来维护的情况下，该服务也可以称为全局元数据服务或者联邦文件系统元数据服务。进一步的，该服务可以由第一计算设备提供、第二计算设备提供或者第三方设备提供等。

应理解，本申请实施例中的发送消息，可以是直接发送方式，也可以间接发送方式。在直接发送方式中，发送方向接收方发送消息。当然，消息可以被复制多份，向多个接收方分别发送消息。间接发送方式有多种实现方式，例如消息队列形式、中间设备转发形式等。以消息队列形式为例，消息队列中的消息可以被一个或者多个设备读取；发送方向消息队列中写入消息，而接收方(接收方数量可以为一个或者多个)可以从消息队列中读取消息，从而实现消息的收发。

方式二，在第一元数据流中追加记录的设备，向共享第一元数据流的设备(或者某些指定设备)发送消息，以指示在第一元数据流中存在新增的记录。

例如，第一计算设备在第一元数据流的末端追加了第一记录。这种情况下，第一计算设备可以向其它设备发送消息，以指示在第一元数据流中存在新增的记录。消息发送方式可以参考前述。

方式三，共享第一元数据流的设备可以监测第一元数据流的变更。例如，第二计算设备主动监测第一元数据流的末端追加了新的记录。

应理解，上述三种方式是为了方便理解而列举的可能的实现方式，具体实施过程中，也可以通过其他方式来发布元数据流的更新。另外，上述三种方式还可以进行结合，以提高元数据流同步的成功率，提升用户体验。

上述是以第一计算设备在元数据流中追加记录为例进行说明，在具体实现过程中，其他设备(例如共享元数据流的设备、再如具有追加记录权限的设备)也可以在元数据流中追加新的记录，此时，其追加记录的方式、通知元数据流变更的方式可以参见前述第一计算设备侧的描述。

在第一元数据流变更时，共享元数据流的设备需要获取元数据流的变更(或者更细后的元数据流)。进一步的，基于元数据流的变更(或者更新后的元数据流)，更新文件视图，以提高视图的有效性和准确性。

以第一计算设备为例，在所述第一元数据流的末端出现新增加的记录的情况下，第一计算设备根据更新后的所述第一元数据流，构建新的文件视图(可以看作更新后的第一文件视图)，该新的文件视图包含更新后的第一文件系统中的多个节点的层次结构。当然，该新增加的记录可以是第一计算设备自己追加的，也可以是其他设备(例如共享元数据流的设备、再如具有追加记录权限的设备)追加的。

前述是以第一计算设备在第一数据流中追加记录为例进行说明，下面对另一种同步文件系统变更的实施方式进行介绍。

作为一种可能的实施方式，第一计算设备可以向第二计算设备发送变更请求，变更请求中指示第一计算设备对文件系统的变更操作。由第二计算设备在第一元数据流的末端追加记录，以使得共享该第一元数据流设备了解文件系统的变更。

在前文中我们提到，文件系统的文件视图有利于用户或业务按需访问文件系统中的文件。然而，在一些可能的情况下，虽然计算设备可以向用户或应用提供第一文件系统的视图，但文件系统的数据却依然存储在远处的存储设备(例如第二计算设备连接的第二存储设备)上，此时，第一计算设备需要从远处的存储设备上获取节点的数据。

作为一种可能的实施方式，元数据流的记录中包含节点的存储布局信息，存储布局信息指示了存储节点的数据内容的设备。第一计算设备可以基于节点的布局信息，从存储节点的数据内容的设备上获取文件的数据内容。

示例性地，第一文件系统中包含第二节点(可选第二节点属于文件)，第二节点的数据内容存储在第一存储盘上。第一元数据流中包含关于第二节点的记录(便于区分称为第三记录)，该第三记录包含第二节点的属性，第二节点的属性中包含第二节点的存储布局信息。例如，第二节点的存储布局信息可以指示第一存储盘所属的存储设备(或指示第一存储盘)。当第一计算设备需要读取第二节点的数据内容时，可以从第一存储盘所属的存储设备和/或第一存储盘获取第二节点的数据。

在一些可能的实施方式中，用户或者业务应用获取节点的数据内容，可以通过发起IO请求(便于区分称为第二IO请求)来实现。例如，主机上运行了业务应用，该业务应用需要读取文件系统中的文件的数据，此时主机可以发起第二IO请求。

作为一种可能的方案，第一计算设备获取第二IO请求，第二IO请求指示读取第二节点的数据内容。第二节点的存储布局信息指示存储设备X，此时，第一计算设备可以从存储设备X获取第二节点的数据内容。进一步的，第一计算设备可以将所述第二节点的数据内容响应给第二IO请求，使得用户或者应用可以获取第二节点的数据内容。

由于设备可以向元数据流中追加记录，因此元数据流中，可能包含一个节点的多个时期的元数据。随着文件系统的变更越来越多，元数据流的数据量越来越大，最终严重影响访问、同步效率。

作为一种可能的实施方式，第一计算设备可以对第一元数据流执行合并操作，将第一元数据流中的同一个节点对应的多条记录合并为一条记录。关于合并操作的相关内容可以参考前述设计6的相关介绍。

可选的，合并操作可以是周期或者非周期的执行。例如，每隔一定时长则对元数据流执行一次合并。

或者可选的，合并操作设置有触发条件。例如，每当有新设备加入共享元数据流的设备中时则执行合并操作。再如，每当CDC流的大小超过预设的CDC流阈值时则执行合并操作。

当然，合并第一元数据的操作也可以由第二计算设备执行，或者由其他共享第一元数据流的设备执行，或者由维护第一元数据流的设备或服务执行，此处不再一一说明。

在图13所示的实施例通过流式结构的元数据流，实现了以统一的方式来表达异构文件系统的元数据，该统一的表达方式能够屏蔽异构文件系统之间元数据管理和访问控制方式的差异，也能屏蔽存储异构文件系统的设备之间的差异。即，通过本申请中统一的流式结构的元数据表达方式，能够拉通异构文件系统之间的元数据，从而使得异构的文件系统中的数据不再是一个个数据孤岛，这会极大地提升用户在数据使用和管理上的便捷性。

图13所示实施例是以第一计算设备获取第二计算设备分享的第一元数据流为例进行描述。在一些可能的设计中，第一计算设备除了接收第一元数据流之外，还可以接收其他元数据流，并基于多个元数据流，确定多个文件系统的层次结构。下面对这种设计进行示例性的介绍，应理解，下文中部分术语、逻辑可以参考前述图13所示实施例中描述。

请参见图15，图15是本申请实施例提供的又一种数据处理方法的方法流程图，可选的，该方法可以应用于前述的元数据共享系统，例如图9、图10、图11、或图12等实施方式所描述的元数据共享系统。

如图15所示的数据处理方法可以包括步骤S1501至步骤S1507中的一个或者多个步骤。应理解，本申请为了方便描述，故通过S1501至S1507这一顺序进行描述，并不旨在限定一定通过上述顺序进行执行。本申请实施例对于上述一个或多个步骤的执行的先后顺序、执行的时间、执行的次数等不做限定。

步骤S1501：第二计算设备根据第一文件系统中的多个节点的层次结构，构建第一元数据流。

可选的，第一文件系统可以存储于与第二计算设备相连接的第一存储盘上。相关描述参见步骤S1301。

步骤S1502：第二计算设备共享第一元数据流。

相关描述参见步骤S1302。

步骤S1503：第三计算设备根据第二文件系统中的多个节点的层次结构，构建第二元数据流。

可选的，第二文件系统可以存储于与第三计算设备相连接的第二存储盘上。相关描述参见步骤S1301。

步骤S1504：第三计算设备共享第二元数据流。

相关描述参见步骤S1302。

步骤S1505：第一计算设备获取第一元数据流和第二元数据流。

相关描述参见步骤S1303。可选的，第一计算设备可以与第三存储盘连接，第三存储盘上可选存储有第三文件系统的数据。

应理解，第一计算设备可以是同时获取第一元数据流和第二元数据流，也可以是先获取其中第一元数据流，再获取第二元数据流，或者反之。

步骤S1506：第一计算设备根据第一元数据流确定第一文件系统中多个节点的层次结构；根据所述第二元数据流确定所述第二文件系统中的多个节点的层次结构。

相关描述参见步骤S1302。

步骤S1603：第一计算设备获取第一元数据流。

相关描述参见步骤S1302。

在图16所示的实施例中，第一计算设备、第二计算设备、第三计算设备通过流式结构的元数据流，实现了元数据的共享和流动；第一计算设备通过既可以通过元数据流获取其他设备上的文件系统的视图，也可以共享自身连接的存储设备上的文件系统的元数据流使其他设备获取文件系统的视图，使得用户或者业务应用可以便捷地查看多个文件系统的层次结构，提升了文件系统的服务质量。另外，多个设备之间通过共享的元数据流来同步文件系统视图，有利于实现多设备系统(指包含多个设备的系统)的松耦合协作，提高系统的灵活性和可扩展性。

下面介绍本申请实施例提供的一种基于元数据流来同步文件系统的场景下，对文件系统中节点的硬链接处理的可能设计。

节点的硬链接是指不同的节点名连接同一个inode的情况。如图17A所示为本申请实施例提供的一种包含硬链接的文件系统的inode的示意图，其中，节点1和节点3下均有指向inode 2的节点。

如图17B所示为本申请实施例提供的一种文件系统的视图，其中，节点1的名称为“水果”，节点1下包含名称为“西红柿.txt”的节点，而该名称为“西红柿.txt”的节点的inode为2；节点2的名称为“蔬菜”，节点2下包含名称为“番茄.txt”的节点，而该名称为“番茄.txt”的节点的inode也为2。可以看出，不同父节点下的不同的节点名指向同一个inode，则名称为“西红柿.txt”的节点和名称为“番茄.txt”的节点为硬链接节点，其所在的文件系统为包含硬链接的文件系统。

包含硬链接的文件系统，其元数据流可能有如下几种情况：

情况一：在构建元数据流时，文件系统中已经存在硬链接节点。此时，元数据流中包含一条节点标识字段和父节点标识字段相同的记录(便于描述以下称为inode和pinode相同的记录)，该记录表示在指定节点(inode号对应的节点)上存在硬链接。进一步的，元数据流中还包含硬链接节点的记录，硬链接节点的记录中，pinode号为硬链接节点的父节点的标识，inode号与前述指定节点的inode号相同。

示例性地，图17C为本申请实施例提供的一种元数据流的示意图，该元数据流为基于图17A所示的文件系统而构建的元数据流。该元数据流中包含记录1701，记录1701的pinode和inode相同，表示在inode为2的节点上存在硬链接。进一步的，数据流中还包括记录1702和记录1703，其中：记录1702中的inode为2，pinode为1，表示在节点1下存在节点2的硬链接节点，该硬链接节点的名称为“西红柿.txt”；记录1703中的inode为2，pinode为3，表示在节点3下存在节点2的硬链接节点，该硬链接节点的名称为“番茄.txt”。

可选的，在存在硬链接节点的文件系统的元数据流中，inode和pinode相同的记录的位置在该inode的硬链接节点对应的记录的位置之前。即，记录1701在元数据流中的顺序先于记录1702和记录1703。

需要说明的是，图17C中所示的“r”表示参考记录1701中的属性。这种实施方式中，硬链接节点的属性可以无需重复存储，进一步缩小元数据流的存储消耗，提高元数据流的更新效率，提升用户体验。

由于文件系统中的节点较多，逐一检查节点是否为硬链接节点需要耗费较多的计算资源以及较长的时间。因此，存在硬链接的节点可以通过数据采集状态(ingestorstate)来记录。

具体地，ingestor state中可以记录文件系统中存在硬链接的节点的inode及其pinode列表。例如，如表1所示是本申请实施例提供的一种ingestor state表，示例性包含存在硬链接的文件inode以及该文件的硬链接节点的pinode列表。

表1ingestor state表

序号	存在硬链接的节点的inode	pinode
			1	2	1，3
……	……	……

可选的，ingestor state可以通过对应关系集合、表格、队列、链表等方式存储，本申请对于ingestor state的存储和传输格式不做限定。例如，ingestor state还可以表示为：2->[1，3]。

作为一种可能的实施方式，ingestor state可以由构建元数据的设备(例如前述的第一计算设备、或第二计算设备等)来维护或者管理，也可以由多个共享元数据流设备中的任一设备来维护或管理，还可以由元数据服务来维护或者管理。

情况二：在已有元数据流的文件系统中，为某一节点创建硬链接，该节点不存在硬链接。

例如，如图18A所示为本申请实施例提供的一种创建硬链接前的文件系统及其元数据流的示意图，其中，图18A的(a)部分为文件系统的inode的示意图，图18A的(b)部分为该文件系统的元数据流的示意图。

由于元数据流中已存在的记录不可以修改，因此，可以向元数据流中追加记录来表示对文件创建了硬链接。如图18B所示为本申请实施例提供的一种创建硬链接后的文件系统及其元数据流的示意图，其中，图18B的(a)部分为文件系统的inode的示意图，图18B的(b)部分为该文件系统的元数据流的示意图。

可以看出，创建硬链接后，元数据流中新增了记录1801、记录1802和记录1803，其中，记录1801的pinode与inode相同(inode的值为2)，表示节点2上创建了硬链接。记录1802中的inode为2，pinode为1，表示在节点1下存在节点2的硬链接节点，该硬链接节点的名称为“西红柿.txt”；记录1803中的inode为2，pinode为3，表示在节点3下存在节点2的硬链接节点，该硬链接节点的名称为“番茄.txt”。

可选的，记录1802和记录1802中节点的属性可以参考记录1801的属性。

作为一种可能的实施方式，记录1802与记录1804的inode和pinode相同(即索引相同)，由于索引相同时，后追加的文件表示对文件的修改，因此，记录1803可以表征节点1的节点2的当前属性。进一步的，在对元数据流进行合并后，记录1802可以得以保留从而准确地表征节点1的节点2的当前属性。

情况三：在已有元数据流的文件系统中，为已存在硬链接的节点再次创建硬链接节点。此时，可以在元数据流中追加记录，以表示新的硬链接节点的目录，无需插入pinode和inode相同的记录。

如图18C所示为本申请实施例提供的又一种创建硬链接后的文件系统及其元数据流的示意图，其中，图18C的(a)部分为文件系统的inode的示意图，图18C的(b)部分为该文件系统的元数据流的示意图。创建硬链接的操作，使得元数据流中新增了记录1805，其中，记录1805中的inode为2，pinode为4，表示在节点4下存在节点2的硬链接节点，该硬链接节点的名称为“番茄.txt”。

作为一种可能的实施方式，首次出现的硬链接节点和后续出现的链接节点可能间隔很远。例如，记录1805在时间上与原本的记录1801可以间隔较远。当然，本申请对于硬链接节点之间的时间间隔不做限定。

作为一种可能的实施方式，创建硬链接节点后，ingestor state需要对应更新。如表2所示是本申请实施例提供的又一种ingestor state表，示例性包含存在硬链接的节点的inode及其pinode列表。

表2ingestor state表

序号	存在硬链接的节点的inode	pinode
			1	2	1，3，4
……	……	……

可选的，更新后的ingestor state还可以表示为：2->[1，3，4]。

情况四：在已有元数据流的文件系统中，删除硬链接节点。此时，可以在元数据流中追加包含删除标记的记录，来表示删除节点的硬链接节点。

如图19A所示为本申请实施例提供的一种删除硬链接节点后的文件系统及其元数据流的示意图，其中，图19A的(a)部分为文件系统的inode的示意图，图19A的(b)部分为该文件系统的元数据流的示意图。其中，元数据流中追加了记录1901，记录1901中的inode为2，pinode为3，变更操作字段指示删除操作，表示删除节点3下的节点2的硬链接节点。

应理解，图19A所示的删除场景中，删除了硬链接节点后，节点2仍然包含多个硬链接。

当删除硬链接节点后，节点被还原为非硬链接节点的情况下，还需要删除pinode和inode相同的记录。如图19B所示为本申请实施例提供的一种删除硬链接节点后的文件系统及其元数据流的示意图，其中，图19B的(a)部分为文件系统的inode的示意图，图19B的(b)部分为该文件系统的元数据流的示意图。其中，文件系统中删除了节点2的硬链接，节点2被恢复为非硬链接的文件。

而元数据流中追加了记录1902、记录1903和记录1904，其中：记录1902中的inode为2，pinode为1，变更操作字段指示删除操作，表示删除节点1下的节点2的硬链接节点；记录1903中的inode为2，pinode为3，属性值包含节点2的属性，表示非硬链接节点2的记录；记录1904的inode为2，pinode为2，变更操作字段指示删除操作，表示删除与之相同索引的记录。

可选的，在将存在硬链接的节点恢复为普通节点(区别存在硬链接的节点)的情况中，inode和pinode相同且包含删除标记的记录的位置，在恢复为普通节点的节点对应的记录之后。即，记录1904在元数据流中的顺序后于记录1903。

应理解，上述在元数据流中追加记录的设备可以为由构建元数据的计算设备，或者为多个共享元数据流设备中的任一设备，还可以为元数据服务。硬链接相关的实施方式可以与前述数据处理方法结合，例如，构建包含硬链接节点的文件系统的元数据流的相关操作可以与步骤S1301结合。再如，在已有元数据流的文件系统中创建硬链接，可以是计算设备接收IO请求后执行的变更操作。结合的情况此处不再一一赘述。

上面说明了本申请实施例的方法，下面提供本申请实施例的装置。

请参见图20，图20是本申请实施例提供的一种计算装置200的结构示意图。该计算装置200可以包括通信模块2001和处理模块2002。该计算装置200用于实现前述的数据处理方法，例如图13、图15或图16所示实施例中的数据处理方法。

可选的，该计算装置200可以为前述实施例中的计算设备、存储设备、控制器等。例如为图9、图11、图13、图15或图16所示实施例中第一计算设备、或第二计算设备、或第三计算设备。再如为图10所示实施例中的第一控制器、第二控制器、或存储设备。再如为图12所示实施例中的存储设备S1、存储设备S2或存储设备S3等。

在一种可能的实施方式中，所述通信模块2001，用于获取第一文件系统的第一元数据流，所述第一元数据流来自第二计算设备，所述第一元数据流为流式结构且包含多条记录，每条记录包含所述第一文件系统中的一个节点的标识、所述一个节点的父节点的标识和所述一个节点的属性；

所述处理模块2002，还用于根据所述第一元数据流，确定所述第一文件系统中的多个节点的层次结构。

在又一种可能的实施方式中，所述处理模块2002，还用于：

在又一种可能的实施方式中，所述处理模块2002和所述通信模块2001，还用于：

在又一种可能的实施方式中，所述通信模块2001，还用于：

获取第一IO请求，所述第一IO请求指示对第一节点执行变更操作。

在又一种可能的实施方式中，所述通信模块2001，还用于：

在又一种可能的实施方式中，所述通信模块2001和所述处理模块2002，还用于：

从所述第一存储盘获取所述第二节点的数据。

在又一种可能的实施方式中，所述第一元数据流中包含第三记录，所述第三记录包含所述第一文件系统中的第二节点的属性，所述第二节点为文件，所述第二节点的属性包含所述第二节点的存储布局信息，所述第二节点的存储布局信息指示所述第一存储盘所属的存储设备。

在又一种可能的实施方式中，所述通信模块2001，还用于：

在又一种可能的实施方式中，所述处理模块2002，还用于：

所述通信模块2001，还用于：

在一种可能的实施方式中，所述处理模块2002，还用于：

可选的，该文件视图V3还可以包含所述第一文件系统中的多个节点的层次结构。

在又一种可能的实施方式中，所述第三文件系统中存在硬链接节点，所述处理模块2002，还用于：

在又一种可能的实施方式中，所述第一数据流中包含第四记录，所述第四记录包含节点标识字段、父节点标识字段和所述第三节点的属性，其中，所述第四记录中的节点标识字段为第三节点的标识，所述第四记录中父节点标识字段为第四节点的标识，所述第四节点为目录。所述通信模块2001，还用于：

在又一种可能的实施方式中，所述通信模块2001，还用于：

在所述第一元数据流的末端追加第八记录，其中：

在又一种可能的实施方式中，所述通信模块2001，还用于：

若所述第三文件不存在所述第三节点的硬链接节点，则在所述第一数据流的末端追加第九记录和第十记录；

图21所示为本申请实施例提供的一种计算设备210的结构示意图。计算设备210是具有计算能力的设备，这里的设备可以是实体的设备，例如控制器、处理器、服务器(如机架式服务器)、主机等，也可能是虚拟的设备，例如虚拟机、容器等。

如图21所示，计算设备210包括：处理器2102和存储器2101，可选包含总线2104、通信接口2103。处理器2102和存储器2101等之间通过总线2104通信。应理解，本申请不限定计算设备210中的处理器、存储器的个数。

存储器2101用于提供存储空间，存储空间中可选存储应用数据、用户数据、操作系统和计算机程序等。存储器2101可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)。存储器2101还可以包括非易失性存储器(non-volatile memory)，例如只读存储器(read-only memory，ROM)，快闪存储器，机械硬盘(hard disk drive，HDD)或固态硬盘(solid state drive，SSD)等。

处理器2102是进行运算的模块，可以包括控制器(例如存储控制器)、中央处理器(central processing unit，CPU)、微图形处理器(graphics processing unit，GPU)、微处理器(microprocessor，MP)、数字信号处理器(digital signal processor，DSP)、协处理器(协助中央处理器完成相应处理和应用)、专用集成电路(Application SpecificIntegrated Circuit，ASIC)、微控制单元(Microcontroller Unit，MCU)等处理器中的任意一种或多种。

通信接口2103用于为所述至少一个处理器提供信息输入或者输出。和/或，所述通信接口2103可以用于接收外部发送的数据和/或向外部发送数据。通信接口2103可以为包括诸如以太网电缆等的有线链路接口，也可以是无线链路(Wi-Fi、蓝牙、通用无线传输及其他无线通信技术等)接口。可选的，通信接口2103还可以包括与接口耦合的发射器(如射频发射器、天线等)，或者接收器等。

总线2104可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图21中仅用一条线表示，但并不表示仅有一根总线或一种类型的总线。总线2104可包括在计算设备210各个部件(例如，存储器2101、处理器2102、通信接口2103)之间传送信息的通路。

本申请实施例中，存储器2101存储有可执行的指令，处理器2102执行该可执行的指令以实现前述的数据处理方法，例如图13、图15或图16等实施例中的数据处理方法。也即，存储器2101上存有用于执行数据处理方法的指令。

本申请实施例还提供了一种计算机可读存储介质。该计算机可读存储介质包括指令，所述指令用于实现前述的数据处理方法，例如图13、图15或图16等实施例中的数据处理方法。

其中，所述计算机可读存储介质可以是计算设备能够存储的任何可用介质，或者是包含一个或多个可用介质的数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘)等。

本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

本申请中实施例提到的“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a、b、或c中的至少一项(个)，可以表示：a、b、c、(a和b)、(a和c)、(b和c)、或(a和b和c)，其中a、b、c可以是单个，也可以是多个。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A、同时存在A和B、单独存在B这三种情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。

以及，除非有相反的说明，本申请实施例使用“第一”、“第二”等序数词是用于对多个对象进行区分，不用于限定多个对象的顺序、时序、优先级或者重要程度。例如，第一容器存储管理装置和第二容器存储管理装置，只是为了便于描述，而并不是表示这第一容器存储管理装置和第一容器存储管理装置的装置结构、部署顺序、重要程度等的不同。

本领域普通技术人员可以理解，实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的保护范围。

Claims

1.一种数据处理方法，其特征在于，应用于第一计算设备，所述方法包括：

获取第一文件系统的第一元数据流，所述第一元数据流为流式结构且包含多条记录，所述多条记录中的每条记录包含所述第一文件系统中的一个节点的标识，所述一个节点的父节点的标识和所述一个节点的属性；所述一个节点为一个文件或一个目录；

2.根据权利要求1所述的方法，其特征在于，

所述一个节点的属性包含以下字段中的一项或者多项：

对所述一个节点执行的变更操作、与所述一个节点相关的事务的标识、所述记录的序列号、所述一个节点的存储布局信息、所述一个节点的扩展属性。

3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

构建第一文件视图，所述第一文件视图包含所述第一文件系统中的多个节点的层次结构。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述第一文件系统的数据存储在第一存储盘上，所述第一元数据流来自第二计算设备，所述第二计算设备与所述第一存储盘相连。

5.根据权利要求4所述的方法，其特征在于，所述第一计算设备位于第一数据中心，所述第二计算设备和所述第一存储盘位于第二数据中心。

6.根据权利要求4或5任一项所述的方法，其特征在于，所述方法还包括：

在所述第一元数据流的末端追加第一记录，所述第一记录中包含所述第一节点的标识，所述第一节点的父节点的标识和所述第一节点的第一属性，所述第一属性包括所述变更操作的类型。

7.根据权利要求6所述的方法，其特征在于，

所述变更操作的类型为新增，所述第一节点是在所述第一文件系统中的新增的文件或目录。

8.根据权利要求6所述的方法，其特征在于，所述第一节点是所述第一文件系统中已经存在的文件或目录，所述第一记录中还包括所述第一记录的序列号；

所述第一元数据流中还包含第二记录，所述第二记录包含所述第一节点的标识、所述第一节点的父节点的标识、所述第一节点的第二属性和所述第二记录的序列号；其中，所述第一记录的序列号和所述第二记录的序列号用于指示所述第一记录产生在所述第二记录之后；

所述变更操作的类型为更新、删除或移动。

9.根据权利要求6-8任一项所述的方法，其特征在于，所述方法还包括：

10.根据权利要求4-9任一项所述的方法，其特征在于，所述第一元数据流中包含第三记录，所述第三记录包含所述第一文件系统中的第二节点的属性，所述第二节点为文件；

所述方法还包括：

获取第二IO请求，所述第二IO请求指示读取所述第二节点；

从所述第一存储盘所属的存储设备获取所述第二节点的数据。

11.根据权利要求3所述的方法，其特征在于，所述方法还包括：

在所述第一元数据流的末端出现新增加的记录的情况下，根据更新后的所述第一元数据流，更新所述第一文件视图，更新后的所述第一文件视图包含更新后的第一文件系统中的多个节点的层次结构。

12.根据权利要求1-11任一项所述的方法，其特征在于，所述方法还包括：

13.根据权利要求1-12任一项所述的方法，其特征在于，所述方法还包括：

构建第二文件视图，所述第二文件视图包含所述第一文件系统中的多个节点的层次结构和所述第二文件系统中的多个节点的层次结构，所述第二文件系统中的多个节点的层次结构基于所述第二元数据流得到。

14.根据权利要求1-13任一项所述的方法，其特征在于，所述方法还包括：

根据所述第三文件系统的多个节点的层次结构，构建第三元数据流，所述第三元数据流为流式结构且包含多条记录，所述第三元数据流的多条记录中的每条记录包含所述第三文件系统中的一个节点的标识、所述第三文件系统中的所述一个节点的父节点的标识和所述第三文件系统中的所述一个节点的属性；

15.根据权利要求14所述的方法，其特征在于，所述方法还包括：

构建第三文件视图，所述第三文件视图包括所述第一文件系统中的多个节点的结构层次和所述第三文件系统中的多个节点的层次结构。

16.根据权利要求14或15所述的方法，其特征在于，所述第二计算设备和所述第一存储盘包含于第一存储设备，所述第一计算设备和所述第三存储盘包含于第二存储设备，所述第一存储设备和所述第二存储设备是异构的。

17.根据权利要求14-16任一项所述的方法，其特征在于，

所述第一文件系统通过第一访问协议被主机访问，所述第三文件系统通过第二访问协议被主机访问，所述第一访问协议与所述第二访问协议不同。

18.根据权利要求1-17任一项所述的方法，其特征在于，所述第一数据流中包含第四记录，所述第四记录包含节点标识字段、父节点标识字段和第三节点的属性，其中，所述第四记录中的节点标识字段为第三节点的标识，所述第四记录中父节点标识字段为第四节点的标识，所述第四节点为目录；

所述方法还包括：

接收第三IO请求，所述第三IO请求指示在第五节点下创建所述第三节点的硬链接节点，所述第五节点为目录；

19.根据权利要求18所述的方法，其特征在于，所述方法还包括：

在所述第一元数据流的末端追加第八记录，其中：

20.根据权利要求19所述的方法，其特征在于，所述方法还包括：

21.一种元数据共享系统，其特征在于，所述元数据共享系统包含第一计算设备和第二计算设备，其中：

所述第二计算设备，用于：

扫描第一文件系统的多个节点的层次结构，所述第一文件系统的数据存储在第一存储盘上，所述第二计算设备与所述第一存储盘相连；

根据所述第一文件系统的多个节点的层次结构，构建第一元数据流，所述第一元数据流为流式结构且包含多条记录，所述第一元数据流中的每条记录包含所述第一文件系统中的一个节点的标识、所述第一文件系统中的所述一个节点的父节点的标识和所述第一文件系统中的所述一个节点的属性；

向所述第一计算设备发送所述第一数据流；

所述第一计算设备，用于：

获取来自所述第二计算设备的第一数据流；

22.根据权利要求21所述的系统，其特征在于，所述第一计算设备，还用于构建第一文件视图，所述第一文件视图包含所述第一文件系统中的多个节点的层次结构；

所述第二计算设备还用于构建第二文件视图，所述第二文件视图包含所述第一文件系统中的多个节点的层次结构。

23.根据权利要求21或22所述的系统，其特征在于，所述第一计算设备，还用于：

在所述第一元数据流的末端追加第一记录，所述第一记录中包含所述第一节点的inode，所述第一节点的pinode，和所述第一节点的第一属性，所述第一节点的第一属性包括所述变更操作的类型；

所述第二计算设备，还用于：

获取所述第一元数据流中的所述第一记录；

24.根据权利要求21-23任一项所述的系统，其特征在于，所述第一计算设备，还用于：

在所述第一元数据流的末端出现新增加的记录的情况下，根据更新后的所述第一元数据流，更新所述第一文件视图，更新的所述第一文件视图包含更新后的所述第一文件系统中的多个节点的层次结构；

所述第二计算设备，还用于：

在所述第一元数据流的末端出现新增加的记录的情况下，根据更新后的所述第一元数据流，更新所述第二文件视图，更新的所述第二文件视图包含更新后的所述第一文件系统中的多个节点的层次结构。

25.根据权利要求21-24任一项所述的系统，其特征在于，所述元数据流中包含第二记录，所述第二记录包含所述第一文件系统中的第二节点的属性，所述第二节点为文件；

所述第一计算设备还用于，还用于：

26.根据权利要求21-25任一项所述的系统，其特征在于，所述第一计算设备或所述第二计算设备，还用于：

27.根据权利要求21-26任一项所述的系统，其特征在于，所述元数据共享系统还包含第三计算设备，所述第三计算设备，用于：

向所述第一计算设备发送第二文件系统的第二元数据流，所述第二文件系统的数据存储在与所述第三计算设备连接的第二存储盘上，所述第二元数据流为流式结构且包含多条记录，所述第二元数据流的多条记录中的每条记录包含所述第二文件系统中的一个节点的标识、所述第二文件系统中的所述一个节点的父节点的标识和所述第二文件系统中的所述一个节点的属性；

所述第一计算设备，还用于：

获取所述第二元数据流，

构建第三文件视图，所述第三文件视图包含所述第一文件系统中的多个节点的层次结构和所述第二文件系统中的多个节点的层次结构，所述第二文件系统中的多个节点的层次结构基于所述第二元数据流得到。

28.根据权利要求21-27任一项所述的系统，其特征在于，所述第一计算设备，还用于：

向所述第二计算设备发送所述第三元数据流；

所述第二计算设备，还用于：

获取来自所述第一计算设备的第三数据流；

29.根据权利要求28所述的系统，其特征在于，所述第二计算设备还用于：

构建第四文件视图，所述第四文件视图包括第一文件系统中的多个节点的层次结构和所述第三文件系统中的多个节点的层次结构。

30.根据权利要求28或29所述的系统，其特征在于，

31.根据权利要求30所述的系统，其特征在于，

32.一种计算装置，其特征在于，所述计算装置包含通信模块和处理模块，其中：

所述通信模块，用于获取第一文件系统的第一元数据流，所述第一元数据流来自第二计算设备，所述第一元数据流为流式结构且包含多条记录，所述多条记录中的每条记录包含所述第一文件系统中的一个节点的标识、所述一个节点的父节点的标识和所述一个节点的属性；

33.一种计算设备，其特征在于，所述计算设备包括处理器和存储器；

所述处理器用于执行所述存储器中存储的指令，以使得所述计算设备实现如权利要求1-20任一项所述的方法。

34.一种计算机可读存储介质，其特征在于，包括计算机程序指令，当所述计算机程序指令由计算设备执行时，使得所述计算设备实现如权利要求1-20任一项所述的方法。

35.一种包含指令的计算机程序产品，其特征在于，当所述指令被计算设备执行时，使得所述计算设备实现如权利要求1-20任一项所述的方法。

36.一种存储系统，其特征在于，包括存储盘和如权利要求33所述的计算设备，所述计算设备和存储盘通过总线或网络相连。