Patent Description:
Cloud bursting is a widely used application deployment architecture in a storage system. A main idea of the cloud bursting is that an application deployed in a local storage system can be migrated to a public cloud when a large quantity of resources (such as computing or storage resources) are required. Resources in the public cloud are used for processing, to save resources of the local storage system.

Before the application is used on the public cloud, all data related to the application needs to be migrated to the public cloud. For example, all data in the local storage system may need to be migrated to the public cloud. However, data migration takes time. Especially, when an amount of data that needs to be migrated is relatively large, longer time is taken to wait for the data migration. Consequently, a processing delay is relatively long, and use of a user is affected.

<CIT> discloses a method for replicating a data container of a source storage server at the logical level in an unordered stream of individual data units. An initial replication operation of the source data container is performed by transferring the data objects within the source data container to a replica data container in the destination storage server as an unordered stream of individual data units while preserving data object identifiers of the source data objects. Afterwards, incremental replication operations can be performed to capture modifications to the source data container over time after the initial replication operation.

<CIT> discloses an example of reading from a clone generated from a snapshot associated with an ongoing replication at a destination storage system, wherein a request to read data associated with a clone of a snapshot, prior to completion of a replication process of the snapshot at a destination storage system, is received at the destination storage system.

<CIT> discloses a data prefetching method. The method includes: a first storage node receives a read request sent by a client, determines a to-be-prefetched data block and a second storage node where the to-be-prefetched data block resides according to a read data block and a set to-be-prefetched data block threshold, and sends a prefetching request to the second storage node, the prefetching request includes identification information of the to-be-prefetched data block, and the identification information is used to identify the to-be-prefetched data block.

This application provides a file system cloning method and apparatus, to resolve a problem of a relatively long delay in an application migration process.

According to a first aspect, a file system cloning method is provided by claim <NUM>.

In the foregoing technical solution, after the destination storage system creates the cloned file system corresponding to the file system in the source storage system, an application running on the file system in the source storage system can also run on the cloned file system. Only a data layout of a source file system is required for creating the cloned file system, and before receiving a data obtaining request sent by the destination storage system, the source storage system does not send data included in any file to the destination storage system. In other words, data of a file included in the file system does not need to be transmitted, and an amount of data in the data layout is less than an amount of data included in the file. In this way, a delay in an application migration process can be reduced.

In a possible design, the first information may include but is not limited to the following two types of content:.

First, the first information includes metadata of all files in the file system.

In the foregoing technical solution, if metadata in the source storage system and metadata in the destination storage system are described in a same manner, the data layout of the file system may be directly indicated by using the metadata. This implementation is simple.

Second, the first information includes semantic analysis information of the metadata of all the files in the file system. Semantic analysis information of metadata of each file includes an identifier of the metadata of the file, an operation corresponding to the metadata of the file, and data required for creating the metadata of the file.

In the foregoing technical solution, if the metadata in the source storage system and the metadata in the destination storage system are described in different manners, the data layout of the file system may be indicated by using the semantic analysis information of the metadata, to improve applicability of the solution. Certainly, if the metadata in the source storage system and the metadata in the destination storage system are described in the same manner, this manner may also be used to indicate the data layout of the file system. This is not limited herein.

Further, either of the foregoing two types of content may be used to indicate the data layout of the file system, to improve flexibility of the solution.

In a possible design, the destination storage system may further receive second information sent by the source storage system. The second information includes metadata of a changed file in the file system or semantic analysis information of the metadata of the changed file. Then, the destination storage system updates the cloned file system based on the second information.

In the foregoing technical solution, after the file in the source storage system is changed, the metadata of the changed file or the semantic analysis information of the metadata may be sent to the destination storage system, to update the cloned file system and implement incremental update.

In a possible design, after the destination storage system receives a data read request including an identifier of a to-be-read data block, when the destination storage system determines that the to-be-read data block is not stored in the destination storage system, the destination storage system may send a first data obtaining request to the source storage system, to obtain the to-be-read data block. The first data obtaining request includes the identifier of the to-be-read data block. After receiving the to-be-read data block from the source storage system, the destination storage system may store the to-be-read data block.

In the foregoing technical solution, the destination storage system may obtain a data block from the source storage system as required, to meet a use requirement of a user. In this way, an unnecessary data block does not need to be sent to the destination storage system, to reduce an amount of data transmitted between the source storage system and the destination storage system.

In a possible design, after receiving the data read request, the destination storage system may further determine a pre-read data block according to a prefetch rule and the data read request, and send a second data obtaining request including an identifier of the pre-read data block to the source storage system, to obtain the pre-read data block. After receiving the pre-read data block from the source storage system, the destination storage system stores the pre-read data block in the destination storage system.

In the foregoing technical solution, the destination storage system may prefetch some data blocks and store the data blocks in the destination storage system, so that when the data read request for the pre-read data block is subsequently received, the data block may be directly read locally. This reduces a response delay.

According to a second aspect,. a file system cloning apparatus is provided by claim <NUM>. The file system cloning apparatus may include a transceiver unit and a creation unit. These units may perform corresponding functions performed in any one of the design examples of the first aspect. Details are as follows:
The transceiver unit is configured to receive first information sent by a source storage system, where a file system runs in the source storage system, and the first information is used to indicate a data layout of the file system.

The creation unit is configured to create a cloned file system of the file system based on the first information.

According to a third aspect, an embodiment of this application provides a computer-readable storage medium of claim <NUM>.

According to a fourth aspect, an embodiment of this application provides a computer program prduct of claim <NUM>.

To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the following further describes the embodiments of this application in detail with reference to the accompanying drawings.

"A plurality of" in the embodiments of this application means two or more than two. In view of this, "a plurality of" in the embodiments of this application may also be understood as "at least two". "At least one" may be understood as one or more, for example, understood as one, two, or more. For example, "including at least one" means including one, two, or more, and does not limit what are included. For example, "including at least one of A, B, and C" may represent the following cases: A is included, B is included, C is included, A and B are included, A and C are included, B and C are included, or A, B and C are included. The term "and/or" describes an association relationship for describing associated objects and represents that three relationships may exist. In addition, the character "/" generally indicates an "or" relationship between the associated objects. In the embodiments of this application, the "node" and the "device" may be used interchangeably.

Unless otherwise stated, in the embodiments of this application, ordinal numbers such as "first" and "second" are used to distinguish between a plurality of objects, and not intended to limit a sequence, a time sequence, a priority, or an importance of the plurality of objects.

A file system cloning method provided in the embodiments of this application may be applied to two storage systems. <FIG> is a schematic diagram of an example of an application scenario according to an embodiment of this application. In <FIG>, a storage system <NUM> and a storage system <NUM> are included. The storage system <NUM> includes a management module <NUM> and at least one storage node <NUM> (in <FIG>, three storage nodes <NUM>, which are respectively a storage node <NUM> to a storage node <NUM>, are used as an example). The management module <NUM> is configured to write data into each storage node <NUM>, and read data from the at least one storage node <NUM>.

The storage node <NUM> in <FIG> may be an independent server, or a storage array including at least one storage device. The storage device may be a hard disk drive (HDD) disk device, a solid state drive (SSD) disk device, a serial advanced technology attachment (SATA) disk device, a small computer system interface (SCSI) disk device, a serial attached SCSI (SAS) disk device, or a fiber channel (FC) disk device.

The management module <NUM> in <FIG> may be an independent server or controller, or the like. The management module <NUM> and the at least one storage node <NUM> may be devices independent of each other. For example, the management module <NUM> is an independent server. Alternatively, the management module <NUM> may be a software module deployed on a storage node <NUM>. For example, the management module <NUM> and the storage node <NUM> run on a same server. Specific forms of the management module <NUM> and the storage node <NUM> are not limited herein. In <FIG>, an example in which the management module <NUM> and the storage node <NUM> are devices independent of each other is used for description.

The storage system <NUM> includes a file system <NUM>. The management module <NUM> runs the file system <NUM> to control manners of writing data into the storage node <NUM> and reading data from the storage node <NUM>. If there is no file system, information placed in storage space of the at least one storage node <NUM> is a large data body, and a start location and an end location of one piece of information cannot be distinguished. Separating the data and naming each piece of data make it easy to separate and identify the information. The data is named based on a naming manner of a paper information system. Each group of data is referred to as a "file". A structure and a logical rule that are used to manage groups of information and names of the groups are referred to as a "file system". Accordingly, the file system <NUM> is responsible for collating files and tracking when the files are changed. Further, the file system <NUM> stores metadata of all files. Metadata of each file includes information such as a file name, a file ID (for example, an index node number), a size of a file data block, a location at which the file is stored in a disk, a timestamp of file creation, and a plurality of timestamps of writing data blocks into the disk. The metadata of all the files in the file system <NUM> is stored on the at least one storage node <NUM> in a distributed manner.

A hardware architecture of the storage system <NUM> is similar to a hardware architecture of the storage system <NUM>. For example, the storage system <NUM> includes a management module <NUM> and at least one storage node <NUM> (which are respectively a storage node <NUM> to a storage node <NUM>). The management module <NUM> is similar to the management module <NUM>. The at least one storage node <NUM> is similar to the at least one storage node <NUM>.

Before the file system is created, storage space used to store data required by the file system may be reserved in the storage system <NUM>. A size of the storage space may be preset, or may be determined by the management module <NUM>. The storage space is distributed on all storage nodes <NUM> or some storage nodes <NUM> in the destination storage system <NUM>. In addition, metadata of files in different types of file systems is described in different manners. An administrator may configure a type and an attribute of the file system through the management module <NUM>. For example, the type of the file system may be a FAT <NUM> file system using a <NUM>-bit file allocation table (FAT) or a new technology file system (NTFS) or a third extended file system (ETX3). The attribute of the file system may include whether the file system is a read-only file system or a readable and writable file system.

In the application scenario shown in <FIG>, the storage system <NUM> is a distributed storage system, and the storage system <NUM> is also a distributed storage system. In another application scenario, the storage system <NUM> or the storage system <NUM> may be a centralized storage system. In some other application scenarios, the storage system <NUM> may alternatively be a cloud storage system such as a public cloud or a private cloud, or both the storage system <NUM> and the storage system <NUM> are cloud storage systems. This is not limited herein.

The following uses the application scenario shown in <FIG> as an example to describe the file system cloning method in the embodiments of this application. <FIG> is a flowchart of the method. The flowchart is described as follows:
S201: The management module <NUM> obtains first information that is stored in the file system <NUM> at a first moment.

In this embodiment of this application, the first information is used to indicate a data layout of the file system <NUM>. The first moment may be used to generally refer to any moment. For example, the management module <NUM> may obtain the first information based on a clone request received from a client that communicates with the storage system <NUM>. In this case, the first moment may be a moment after the clone request is received. Alternatively, the management module <NUM> may periodically and actively obtain the first information. In this case, the first moment may be a start moment of any period. This is not limited herein.

That the management module <NUM> obtains the first information may include but is not limited to the following two manners:
A first obtaining manner is as follows:
Because information such as the file name, the file ID, a file size, and the location at which the file is located in the disk is recorded in the metadata of each file in the source storage system <NUM>, if the metadata of all the files in the file system <NUM> is obtained and identified, the data layout of the file system <NUM> may be obtained. For example, the file system <NUM> includes metadata corresponding to a directory A, metadata corresponding to a file a, metadata corresponding to a directory B, and metadata corresponding to a file b. The metadata corresponding to the directory A includes a name of the directory A, an ID of a file and an ID of a directory (the directory B) that are included in the directory A, a size of the file included in the directory A, a size of a data block included in the directory A, or the like. The metadata corresponding to the file a includes a name of the file a, a size of the file a, a size of a data block included in the file a, or the like. The metadata corresponding to the directory B includes a name of the directory B, an ID of a file included in the directory B, a size of a data block included in the directory B, or the like. The metadata corresponding to the file b includes a name of the file b, a size of the file b, a size of a data block included in the file b, or the like. For the foregoing information, refer to a data layout shown in <FIG>. Therefore, in this manner, the first information is the metadata of all the files in the file system <NUM>.

In an example, the management module <NUM> may obtain, in a manner of creating a snapshot for the file system <NUM>, metadata of all the files that are stored in the file system <NUM> at the first moment. For example, the first information, obtained by the management module <NUM>, that is stored in the file system <NUM> at the first moment is the metadata corresponding to the directory A, the metadata corresponding to the file a, the metadata corresponding to the directory B, and the metadata corresponding to the file b. Content included in each piece of metadata is similar to the foregoing content, and details are not described herein again.

It can be learned from the first obtaining manner that the data layout of the file system <NUM> may be obtained by using the metadata of all the files in the file system <NUM>. However, it can be learned from the foregoing description of the file system that the metadata of the files in the different types of file systems is described in different manners. Therefore, a prerequisite for implementing the first manner is that a management module (for example, the management module <NUM> of the storage system <NUM>) that receives the first information describes metadata of a file in a same manner. If the management module that receives the first information describes the metadata of the file in a different manner, the management module that receives the first information cannot obtain correct metadata.

In view of this, a second obtaining manner is provided, and details are as follows:
After obtaining metadata of all the files/directories that are stored in the file system <NUM> at the first moment, the management module <NUM> may perform semantic analysis on the metadata of each file, and generate semantic analysis information corresponding to the metadata of each file. Each piece of semantic analysis information includes an identifier of the metadata, an operation corresponding to the metadata, and data required for creating the metadata. The identifier of the metadata and the data required for creating the metadata may be obtained from the metadata of each file, and details are not described herein again. The following describes the operation, corresponding to the metadata, that is in the semantic analysis information.

In this embodiment of this application, in addition to the foregoing content included in the metadata of each file, information used to indicate a type of the metadata is further recorded in a block header or a data integrity field (DIF) of the metadata of each file. The type of the metadata may include a data type, a directory type, an access permission type, and the like. Types of the metadata may be classified by the management module <NUM> based on different file names of files corresponding to the metadata or different content included in file data blocks. For example, if a file name of a file includes a "file" field, the management module <NUM> determines that a type of metadata corresponding to the file is the data type. Alternatively, if a file data block of a file is user data, the management module <NUM> determines that a type of metadata corresponding to the file is the data type. Certainly, the type of the metadata of each file may alternatively be determined in another manner, and details are not described herein.

Then, the management module <NUM> may determine, based on the type of the metadata of each file, an operation corresponding to the metadata of each file. In the file system <NUM>, different types of metadata correspond to different operations. For example, the file system <NUM> may include different metadata creation functions. When metadata of the data type is created, a corresponding metadata creation function may be a function X. In this case, an operation corresponding to the metadata of the data type is an operation of invoking the function X. When metadata of the directory type is created, a corresponding metadata creation function is a function Y. In this case, an operation corresponding to the metadata of the directory type is an operation of invoking the function Y.

In this manner, the first information is semantic analysis information of the metadata of all the files in the file system <NUM> in the storage system <NUM>.

In an example, the foregoing example is still used. The file system <NUM> includes the metadata corresponding to the directory A, the metadata corresponding to the file a, the metadata corresponding to the directory B, and the metadata corresponding to the file b. After obtaining the metadata corresponding to the directory A, the management module <NUM> performs semantic analysis on the metadata. In this case, obtained semantic analysis information of the metadata corresponding to the directory A is as follows: An identifier of the metadata is the directory A; data required for creating the metadata corresponding to the directory A is that the ID of the file and the ID of the directory that are included in the directory A are respectively an ID of the file a and an ID of the directory B; and the size of the data block is <NUM> MB. Then, the management module <NUM> may determine, based on a block header or a data integrity field DIF of the metadata, that a type of the metadata is the directory type, and further determine that an operation on the metadata is the operation of invoking the function X. In this case, the obtained semantic analysis information of the metadata corresponding to the directory A is as follows: The function X is invoked to create metadata, where an identifier of the metadata is the directory A, a size of a data block is <NUM> MB, and the metadata includes the file a and the directory B. Semantic analysis is performed on metadata of another file in a same manner, and details are not described herein again.

In a possible implementation, when the metadata of the files in the file system <NUM> is stored on the storage nodes <NUM> in a distributed manner, the management module <NUM> may send a snapshot obtaining request to each storage node <NUM>. After receiving the snapshot obtaining request, each storage node <NUM> creates a snapshot for metadata of a file stored in the storage node <NUM>, and sends the obtained snapshot of the metadata to the management module <NUM>, so that the management module <NUM> obtains, from the snapshot corresponding to each storage node <NUM>, the metadata stored in the file system <NUM> at the first moment.

In another possible implementation, in the storage system <NUM>, storage space corresponding to the at least one storage node <NUM> may be divided into a plurality of domains. For example, the storage node <NUM> may include two domains, the storage node <NUM> may include three domains, and data in each domain may be independently managed. For example, the management module <NUM> may perform a hash operation based on the file name and the ID of the metadata of each file to obtain a domain name corresponding to the metadata of each file, and then store the metadata in a corresponding domain. The data in each domain may be independently managed. Therefore, each storage node <NUM> may separately create a snapshot for metadata of a file stored in each domain, to obtain snapshots of metadata corresponding to a plurality of domains included on the storage node <NUM>. Then, the first obtaining manner or the second obtaining manner is used to obtain the metadata of the file in each domain or parsing information of the metadata.

S202: The management module <NUM> of the storage system <NUM> sends the first information to the management module <NUM> of the storage system <NUM>.

The management module <NUM> may sequentially send the first information. Alternatively, the management module <NUM> may divide the first information into a plurality of pieces of information based on a source (from different storage nodes or different domains) of each piece of information in the first information, and send the plurality of pieces of information in parallel, so that a data transmission speed can be increased. This is not limited herein.

S203: The management module <NUM> of the storage system <NUM> creates a cloned file system based on the first information.

Based on different content in the first information, manners in which the management module <NUM> of the storage system <NUM> creates the cloned file system based on the first information are also different. The manners may include but are not limited to the following two manners.

A first creation manner is as follows:
When the first information is the metadata of all the files in the file system <NUM>, the management module <NUM> obtains the metadata corresponding to the files from the first information, and then the management module <NUM> may create cloned metadata in the storage space that is reserved in the storage system <NUM> and that is used to store the data required by the file system. After cloned metadata of all the files is created, a cloned file system shown in <FIG> is obtained.

The plurality of pieces of cloned metadata may be created on a same storage node, or may be separately created on different storage nodes. In this embodiment of this application, a storage node on which the cloned metadata is located is not limited.

A second creation manner is as follows:
When the first information is the semantic analysis information of the metadata of all the files in the file system <NUM>, the management module <NUM> creates cloned metadata on a corresponding storage node <NUM> based on an operation indicated in each piece of semantic analysis information and the data required for creating the metadata.

In an example, the management module <NUM> obtains four pieces of semantic analysis information from the first information. Content of each piece of semantic analysis information is the same as the foregoing content, and details are not described herein again. In this case, the management module <NUM> creates cloned metadata corresponding to the four pieces of semantic analysis information, and establishes, based on an ID of a file and/or an ID of a directory that are/is included in metadata of each directory type, an association relationship between the cloned metadata. For example, if an ID of a file and an ID of a directory that are included in the semantic analysis information corresponding to the metadata of the directory A are respectively the ID of the file a and the ID of the directory B, the management module <NUM> establishes an association relationship between the directory A, the file a, and the directory B, and establishes an association relationship between the directory B and the file b in a same processing manner. In this way, the cloned file system shown in <FIG> is obtained.

In some other embodiments, when cloning the metadata of each file, the management module <NUM> may update a file name of each file according to a preset rule. For example, if a file name in metadata of a file is the directory A, when cloning the metadata of the file, the management module <NUM> may update the file name to a directory A', to create metadata of the directory A', and establish a one-to-one mapping relationship between source metadata and the cloned metadata (for example, the metadata of the directory A and the metadata of the directory A'). Metadata of another file is also processed in a same manner, to obtain a cloned file system shown in (a) in <FIG>.

The foregoing technical solution provides a solution of creating the cloned file system based on the metadata of the file system, and the cloned file system can be created in the destination storage system by only sending metadata in the source storage system to the destination storage system without copying any user data, so that an amount of transmitted data can be reduced, and efficiency of cloning the file system can be improved.

Because the data in the file system dynamically changes, the cloned file system in the storage system <NUM> further supports an incremental update operation. A flowchart shown in <FIG> further includes the following steps.

S204: The management module <NUM> of the storage system <NUM> determines metadata updated between the first moment and a second moment.

The second moment may be any moment after the first moment. Alternatively, if the management module <NUM> periodically obtains updated metadata in the file system <NUM>, the second moment is a start moment of a period. The management module <NUM> may obtain a snapshot of the file system <NUM> that is at the second moment, and then compare an obtained snapshot for the first moment with the obtained snapshot for the second moment, to obtain the metadata updated between the first moment and the second moment.

The updated metadata may include but is not limited to the following two cases:
In a first case, the data layout of the file system <NUM> remains unchanged, and the metadata changes because a data block changes. For example, the file system <NUM> includes, at the first moment, the metadata corresponding to the directory A, the metadata corresponding to the file a, the metadata corresponding to the directory B, and the metadata corresponding to the file b. Content included in the metadata of each file is described above, and details are not described herein again. After the first moment, the management module <NUM> updates a data block of the file a based on an operation of the client, for example, updates the file a from a data block <NUM> to a data block <NUM>. Because the data block changes, the metadata corresponding to the file a also changes. In this case, metadata corresponding to the file a that includes the data block <NUM> is the updated metadata.

In a second case, the data layout changes due to a newly added file. For example, after the first moment, the file system <NUM> adds a new file c to the directory B, so that metadata corresponding to the file c is added to the file system <NUM>. A file name included in the metadata corresponding to the file c is the file c, and a size of a data block is <NUM> MB. In this case, the metadata corresponding to the file c is the updated metadata.

Certainly, the updated metadata may further include another case, and examples are not listed one by one herein.

S205: The management module <NUM> sends the updated metadata to the management module <NUM> of the storage system <NUM>.

After obtaining the updated metadata, the management module <NUM> may send the updated metadata or semantic analysis information of the updated metadata to the management module <NUM>. In <FIG>, sending the metadata is used as an example for description. For example, the metadata corresponding to the file a that includes the data block <NUM> and the metadata corresponding to the file c are sent to the management module <NUM>.

S206: The management module <NUM> of the storage system <NUM> updates the cloned file system based on the updated metadata.

After receiving the updated metadata, the management module <NUM> may first determine whether the updated metadata is metadata corresponding to the newly added file or metadata generated by updating an existing file, and then perform a corresponding operation based on a determining result. If the updated metadata is the metadata generated by updating the existing file, the management module <NUM> first deletes old metadata corresponding to the updated metadata in the cloned file system, and then creates new cloned metadata of the file in the cloned file system based on the updated metadata. If the updated metadata is the metadata corresponding to the newly added file, the management module <NUM> directly creates cloned metadata in the cloned file system based on the updated metadata.

For example, the management module <NUM> queries file names of all metadata stored in the storage system <NUM>, and determines whether metadata whose file name is the same as a file name of the updated metadata exists in the cloned file system. If the metadata exists, it indicates that the updated metadata is the metadata generated by updating the existing file. For example, the file name included in the updated metadata is the file a. If the management module <NUM> determines that cloned metadata corresponding to the file a already exists in the cloned file system, the management module <NUM> deletes the metadata corresponding to the file a in the cloned file system, and then recreates, based on the updated metadata, cloned metadata corresponding to the file a. For ease of description, the cloned metadata that is corresponding to the file a and that is created based on the updated metadata is marked as metadata corresponding to a file a". Then, the management module <NUM> establishes a mapping relationship between the metadata corresponding to the file a and the metadata corresponding to the file a", to obtain a data layout shown in (b) in <FIG>.

If the management module <NUM> queries the file names of all the metadata stored in the storage system <NUM>, and determines that no metadata whose file name is the same as the file name of the updated metadata exists in the cloned file system, the updated metadata is the metadata corresponding to the newly added file. For example, if the management module <NUM> determines that the cloned file system does not include cloned metadata corresponding to the file c, the management module <NUM> creates, in the cloned file system and based on the updated metadata, the cloned metadata corresponding to the file c, to obtain a data layout shown in (c) in <FIG>.

In the foregoing technical solution, the source storage system may send the updated metadata to the destination storage system, to maintain data consistency between a source file system and the cloned file system.

The cloned file system created in the storage system <NUM> may provide data access for a user. The following separately describes a process in which the cloned file system processes a data read request and a process in which the cloned file system processes a write request.

<FIG> is a flowchart of processing the data read request by the cloned file system. The flowchart is described as follows:
S501: The management module <NUM> of the storage system <NUM> receives a data read request sent by the client, where the data read request includes an identifier of a to-be-read data block.

In this embodiment of this application, the identifier of the to-be-read data block includes a file name of a file to which the to-be-read data block belongs, and a start address and a length of the to-be-read data block. The start address of the to-be-read data block may be indicated by an offset from an initial address (<NUM>). The length of the to-be-read data block may be a quantity of fixed-size data blocks (for example, <NUM> KB data blocks). In an example, the identifier of the to-be-read data block includes the file a, the start address is <NUM>, and the length is <NUM>. In other words, the to-be-read data block is a first <NUM> KB data block of the file a.

S502: The management module <NUM> determines whether the to-be-read data block is stored in the storage system <NUM>.

For the metadata of the data type, after creating cloned metadata in the storage system <NUM>, the management module <NUM> may further create a bitmap or a bit-tree corresponding to the cloned metadata. The bitmap or the bit-tree is used to indicate whether a data block corresponding to the metadata is stored in storage space corresponding to the cloned metadata. The bitmap is used as an example. The bitmap may include a plurality of bits, and each bit is used to indicate whether a data block is stored in a physical address segment with a fixed size. For example, the fixed size is a size (for example, <NUM> KB) of a sector, and a size of the data block of the file a is <NUM> KB. In this case, a bitmap corresponding to the file a includes <NUM> bits. The data block of the file a is stored in a first disk of the storage node <NUM>, and a start address is <NUM>. In this case, a first bit is used to indicate whether the data block is stored in a first sector of the first disk, a second bit is used to indicate whether a data block is stored in a second sector of the first disk, and so on. Because only the metadata of the file system <NUM> is cloned in the storage system <NUM>, after the cloning method shown in <FIG> is performed by the storage system <NUM>, the data block of the file a may not be stored in the storage system <NUM>. In this case, each bit in the bitmap corresponding to the file a indicates that no data block is stored in a corresponding physical address segment. For example, values of the <NUM> bits corresponding to the file a are all <NUM>.

In an example, when the management module <NUM> determines that the to-be-read data block is the first <NUM> KB data block of the file a, the management module <NUM> first determines whether values of first <NUM> bits in the bitmap corresponding to the file a are <NUM>. If the values are <NUM>, the management module <NUM> determines that the to-be-read data block is not stored in the storage system <NUM>.

In another example, when cloning the metadata of each file, the management module <NUM> may update the file name of each file according to the preset rule, to create the cloned file system shown in (a) in <FIG>. In this way, after receiving the data read request again, the management module <NUM> first needs to determine, based on the one-to-one mapping relationship between the source metadata and the cloned metadata that is stored in the storage system <NUM>, that a data block of the file a' is to be read in the data read request, and then determines, based on a bitmap corresponding to the file a', whether the to-be-read data block is stored in the storage system <NUM>.

S503: When the to-be-read data block is not stored in the storage system <NUM>, the management module <NUM> sends a first data obtaining request to the source storage system <NUM>.

The first data obtaining request may include the identifier of the to-be-read data block. The identifier of the to-be-read data block is the same as that in step S501, and details are not described herein again. In an example, the identifier of the to-be-read data block includes the file a, the start address is <NUM>, and the length is <NUM>. In other words, the to-be-read data block is the first <NUM> KB data block of the file a.

It should be noted that the first data obtaining request may be the data read request sent by the client in step S501. In other words, the data read request is directly forwarded. Alternatively, the first data obtaining request may be a data obtaining request obtained by the management module <NUM> after parsing the received data read request. This is not limited herein.

S504: The management module <NUM> obtains the to-be-read data block, and sends the to-be-read data block to the management module <NUM>.

After obtaining the data obtaining request, the management module <NUM> obtains the to-be-read data block based on the identifier that is of the to-be-read data block and carried in the data obtaining request, for example, obtains the first <NUM> KB data block of the file a; and sends the data block to the management module <NUM>.

S505: The management module <NUM> stores the to-be-read data block.

After obtaining the to-be-read data block, the management module <NUM> stores the to-be-read data block in storage space corresponding to the to-be-read data block. For example, if the first <NUM> KB data block of the file a is stored in sectors <NUM> to <NUM> of the storage node <NUM>, the management module <NUM> writes the to-be-read data block into the sectors <NUM> to <NUM> of the storage node <NUM>. In this case, a data layout shown in (d) in <FIG> may be obtained. In (d) in <FIG>, the file data block corresponding to the file a' is displayed below the file a', to indicate that the data block included in the file is already stored in the destination storage system <NUM>.

Further, because the data block included in the file a is already stored in the storage system <NUM>, the management module <NUM> changes the bitmap corresponding to the file a, for example, sets the values of the first <NUM> bits in the bitmap corresponding to the file a to <NUM>, to indicate that the first <NUM> KB data block of the file a is already stored in storage space corresponding to the file a.

S506: The management module <NUM> sends the to-be-read data block to the client.

In this embodiment of this application, step S505 and step S506 are not subject to an execution sequence.

In addition, if the to-be-read data block is stored in the destination storage system <NUM>, the management module <NUM> does not need to perform step S503 to step S505, but directly obtains the to-be-read data block from the corresponding storage space, and sends the to-be-read data block to the client. Therefore, step S503 to step S505 are optional steps, and are represented by dashed lines in <FIG>.

S507: The management module <NUM> sends a second data obtaining request to the source storage system <NUM>, where the second data obtaining request includes an identifier of a pre-read data block.

The management module <NUM> may further prefetch some data to a cache of the management module <NUM> based on the data read request. For example, the data read request is used to read the first <NUM> KB data block of the file a. In this case, the management module <NUM> speculates, according to a preset prefetch rule, that the user will subsequently read a last <NUM> KB data block of the file a, and the management module <NUM> may send the second data obtaining request to the storage system <NUM>. The second data obtaining request carries an identifier of the last <NUM> KB data block of the file a.

S508: The management module <NUM> obtains the pre-read data block, and sends the pre-read data block to the management module <NUM>.

The management module <NUM> obtains the last <NUM> KB data block of the file a based on the second data obtaining request, and sends the last <NUM> KB data block of the file a to the management module <NUM>.

S509: The management module <NUM> caches the pre-read data block.

After receiving the pre-read data block, the management module <NUM> stores the pre-read data block in the cache of the management module <NUM>. In this way, after subsequently receiving a corresponding data read request used to obtain the pre-read data block, the management module <NUM> may directly obtain the data block from the cache and send the data block to the client, to reduce a delay.

Step S507 to step S509 are optional steps, and are represented by dashed lines in <FIG>.

When the cloned file system in the storage system <NUM> is a readable and writable file system, the management module <NUM> of the storage system <NUM> may further process a write request. In this embodiment of this application, the write request may include a data write request, a file creation request, a file deletion request, or the like. In the following, an example in which the write request is the data write request is used.

<FIG> is a flowchart of processing the data write request by the storage system <NUM>. The flowchart is described as follows:.

In an example, if the management module <NUM> determines that the to-be-written data block is a data block corresponding to the file a, the management module <NUM> stores the to-be-written data block in the storage space corresponding to the file a. For example, the storage space of the file a is sectors <NUM> to <NUM> of the storage node <NUM>. In this case, the management module sequentially writes the to-be-written data block into the sectors <NUM> to <NUM>.

It should be noted that, if the data block corresponding to the file a is already stored in the storage system <NUM>, the management module <NUM> may replace the previously stored data block corresponding to the file a with the to-be-written data block in an overwrite manner.

In some other embodiments, when cloning the metadata of each file, the management module <NUM> may update the file name of each file according to the preset rule, to create the cloned file system shown in (a) in <FIG>. In this way, after receiving the data write request again, the management module <NUM> first needs to determine, based on the one-to-one mapping relationship between the source metadata and the cloned metadata that is stored in the storage system <NUM> and the identifier that is of the to-be-written data block and that is included in the data write request, metadata corresponding to the to-be-written data block. For example, if the file name carried in the data write request is the file a, and the mapping relationship includes that the file a corresponds to the file a', the management module <NUM> determines that the data block carried in the data write request is a data block corresponding to the file a'. Then, the to-be-written data block is written into storage space corresponding to the metadata.

When the write request is the file creation request, the file deletion request, or the like, the management module <NUM> may create a new file or delete a file in the cloned file system by using steps similar to those in <FIG> or <FIG>.

In the foregoing embodiments provided in this application, to implement functions in the method provided in the embodiments of this application, the storage system may include a hardware structure and/or a software module, and implement the functions in a form of the hardware structure, the software module, or a combination of the hardware structure and the software module. Whether a function of the foregoing functions is performed by the hardware structure, the software module, or the combination of the hardware structure and the software module depends on specific application and a design constraint of the technical solution.

<FIG> is a schematic diagram of a structure of a file system cloning apparatus <NUM>. The file system cloning apparatus <NUM> may be a device in which the management module <NUM> in the embodiment shown in <FIG>, <FIG>, or <FIG> is located, or may be located in a device in which the management module <NUM> is located, and may be configured to implement a function of the management module <NUM>. The file system cloning apparatus <NUM> may be a hardware structure or a combination of a hardware structure and a software module.

The file system cloning apparatus <NUM> includes at least one memory, configured to store a program instruction and/or data. The file system cloning apparatus <NUM> further includes at least one processor. The at least one processor is coupled to the memory, and the at least one processor may execute the program instruction stored in the memory.

The file system cloning apparatus <NUM> may include a creation unit <NUM> and a transceiver unit <NUM>.

The creation unit <NUM> may invoke the processor to execute the program instruction stored in the memory, to perform step S203 and step S206 in the embodiment shown in <FIG>, or step S502, step S505, and step S509 in the embodiment shown in <FIG>, or step S602 in the embodiment shown in <FIG>, and/or another process used to support the technology described in this specification.

The transceiver unit <NUM> may invoke the processor to execute the program instruction stored in the memory, to perform step S202 and step S205 in the embodiment shown in <FIG>, or step S501, step S503, step S504, and step S506 to step S508 in the embodiment shown in <FIG>, or step S601 in the embodiment shown in <FIG>, and/or another process used to support the technology described in this specification. The transceiver unit <NUM> is used by the file system cloning apparatus <NUM> to communicate with another module, and may be a circuit, a component, an interface, a bus, a software module, a transceiver, or any other apparatus that can implement communication.

All related content of the steps in the foregoing method embodiments may be cited in function descriptions of corresponding function modules.

Division into modules in the embodiment shown in <FIG> is an example, is merely logical function division, and may be other division in an actual implementation. In addition, functional modules in the embodiments of this application may be integrated into one processor, or each of the modules may exist alone physically, or two or more modules may be integrated into one module. The integrated module may be implemented in a form of hardware, or may be implemented in a form of a software functional module.

<FIG> shows a file system cloning apparatus <NUM> according to an embodiment of this application. The file system cloning apparatus <NUM> may be a device in which the management module <NUM> in the embodiment shown in <FIG>, <FIG>, or <FIG> is located, or may be located in a device in which the management module <NUM> is located, and may be configured to implement a function of the management module <NUM>.

The file system cloning apparatus <NUM> includes at least one processor <NUM>, configured to implement or support the file system cloning apparatus <NUM> to implement the function of the management module <NUM> in the method provided in the embodiments of this application. For example, the processor <NUM> may create a cloned file system based on first information. For details, refer to detailed descriptions in the method example.

The file system cloning apparatus <NUM> may further include at least one memory <NUM>, configured to store a program instruction and/or data. The coupling in this embodiment of this application is an indirect coupling or a communication connection between apparatuses, units, or modules, may be in an electrical form, a mechanical form, or another form, and is used for information exchange between the apparatuses, the units, or the modules. The processor <NUM> may operate with the memory <NUM>. The processor <NUM> may execute the program instruction stored in the memory <NUM>. At least one of the at least one memory may be included in the processor.

The file system cloning apparatus <NUM> may further include a communications interface <NUM>, configured to communicate with another device through a transmission medium, so that the file system cloning apparatus <NUM> may communicate with the another device. For example, the another device may be a client or a storage device. The processor <NUM> may send and receive data through the communications interface <NUM>.

In this embodiment of this application, a specific connection medium between the communications interface <NUM>, the processor <NUM>, and the memory <NUM> is not limited. In this embodiment of this application, the memory <NUM>, the processor <NUM>, and the communications interface <NUM> are connected through a bus <NUM> in <FIG>, and the bus is represented by a thick line in <FIG>. A connection manner between other components is schematically described, and is not limited thereto. The bus may be classified into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is used to represent the bus in <FIG>, but this does not mean that there is only one bus or only one type of bus.

In this embodiment of this application, the processor <NUM> may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or another programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and may implement or execute the methods, steps, and logical block diagrams disclosed in the embodiments of this application. The general purpose processor may be a microprocessor, any conventional processor, or the like. The steps of the methods disclosed with reference to the embodiments of this application may be directly performed by a hardware processor, or may be performed by a combination of hardware and software modules in the processor.

In this embodiment of this application, the memory <NUM> may be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), or may be a volatile memory, such as a random access memory (RAM). The memory is any other medium that can be used to carry or store expected program code in a form of an instruction or a data structure and that can be accessed by a computer. However, this is not limited thereto. The memory in this embodiment of this application may alternatively be a circuit or any other apparatus that can implement a storage function, and is configured to store the program instruction and/or the data.

An embodiment of this application further provides a computer-readable storage medium, including an instruction. When the instruction is run on a computer, the computer is enabled to perform the method performed by the management module <NUM> in the embodiment shown in <FIG>, <FIG>, or <FIG>.

An embodiment of this application further provides a computer program product including an instruction. When the instruction is run on a computer, the computer is enabled to perform the method performed by the management module <NUM> in the embodiment shown in <FIG>, <FIG>, or <FIG>.

An embodiment of this application provides a storage system. The storage system includes a source storage system and a destination storage system. The destination storage system includes the management module <NUM> in the embodiment shown in <FIG>, <FIG>, or <FIG>.

Claim 1:
A file system cloning method, comprising:
receiving (S202), by a destination storage system (<NUM>), first information sent by a source storage system (<NUM>), wherein a file system (<NUM>) runs in the source storage system (<NUM>), and the first information is used to indicate a data layout of the file system (<NUM>); and
creating (S203), by the destination storage system (<NUM>), a cloned file system of the file system (<NUM>) based on the first information,
wherein the first information comprises semantic analysis information of metadata of all files in the file system (<NUM>), and semantic analysis information of metadata of each file comprises an identifier of the metadata of the file, an operation corresponding to the metadata of the file, and data required for creating the metadata of the file,
wherein the method comprises: creating, by the destination storage system (<NUM>), cloned metadata on a storage node of the destination storage system corresponding to a storage node of the source storage system based on an operation indicated in each piece of semantic analysis information and the data required for creating the metadata.