A storage access method and system

Abstract

The application provides a storage access method and system, which is applied to a business data migration scenario from a first storage device to a second storage device of a client, and can avoid business interruption of the client. For example, the business data includes data corresponding to at least one directory in a target directory structure, the client can request the second storage device to access the data corresponding to the i-th directory in the target directory structure by using a handle of the i-th directory in the first storage device; then, when the client receives access error information fed back by the second storage device, the client can request the second storage device to access a handle corresponding to the i-th directory in the second storage device by using a handle of the i-1-th directory in the first storage device and a directory name of the i-th directory; finally, the client can continue to access the corresponding data by using the handle corresponding to the i-th directory in the second storage device.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a storage access method and system. Background Technology

[0002] Network attached storage (NAS) supports managed file systems and uses a directory structure to store client business data.

[0003] File systems can be migrated between different NAS devices. When a file system hosted on a source NAS is migrated to a target NAS for service cutover, the client needs to disconnect from the source NAS and remount to the target NAS. This requires restarting the client's services, which can lead to service interruption and affect user experience. Summary of the Invention

[0004] This application provides a storage access method and system that can ensure the normal operation of business during the migration of the file system between different storage devices (such as NAS), thereby improving the user experience.

[0005] In a first aspect, embodiments of this application provide a storage access method, including:

[0006] After the data corresponding to at least one level directory in the target directory structure in the first storage device is migrated to the second storage device, the client sends a first request message to the second storage device. The first request message is used to request access to the data corresponding to the i-th level directory in the target directory structure. The first request message includes the handle of the i-th level directory in the first storage device; i is a positive integer greater than 1.

[0007] The client receives access error information from the second storage device in response to the first request message; wherein, the access error information is fed back by the second storage device when the handle of the i-th level directory corresponding to the first storage device does not match the handle of the i-th level directory corresponding to the second storage device.

[0008] The client sends a second request message to the second storage device. The second request message is used to request access to the handle of the i-th level directory in the second storage device. The second request message includes the directory name of the i-th level directory and the handle of the (i-1)-th level directory in the first storage device.

[0009] If the client receives the handle of the i-th level directory in the second storage device from the second storage device, then it sends an updated first request message to the second storage device and receives the data corresponding to the i-th level directory from the second storage device; wherein, the handle of the i-th level directory in the second storage device is fed back by the second storage device when the handle of the (i-1)-th level directory in the first storage device matches the handle of the (i-1)-th level directory in the second storage device; the updated first request message includes the handle of the i-th level directory in the second storage device.

[0010] Based on the above design, when business data is migrated between storage devices and business cutover is performed, the client can detect the change of the handle. By combining the source storage handle corresponding to the parent directory of the directory to be accessed, the handle of the directory to be accessed is updated. The client does not need to remount to the target storage device, which can keep the client's business uninterrupted and improve the user experience.

[0011] In one possible design, when i is greater than 2, the following process is further included: repeatedly performing the following process until the client receives the correct handle to be accessed from the second storage device: if the client receives access error information from the second storage device in response to the second request message, the client sends an updated second request message to the second storage device, wherein the value of i in the updated second request message is changed to i-1 compared to the previous second request message;

[0012] Based on the correct handle received from the second storage device, the client determines the handle in the second storage device corresponding to the i-th level directory included in the first request message.

[0013] The client requests access to the data corresponding to the i-th level directory included in the first request message from the second storage device based on the handle in the second storage device corresponding to the i-th level directory included in the first request message.

[0014] Based on the above design, when business data is migrated between storage devices and business cutover is performed, the client can detect the change of handle. By combining the source storage handles corresponding to the multi-level directories before the directory to be accessed, the handle of the directory to be accessed is updated. The client does not need to remount to the target storage device, which can keep the client's business uninterrupted and improve the user experience.

[0015] In one possible design, when i equals 2, it also includes:

[0016] If the client receives access error information from the second storage device in response to the second request message, it initiates a reload request for the target directory structure to the second storage device; wherein, the access error information is fed back by the second storage device when the handle of the first-level directory included in the second request message in the first storage device does not match the handle of the first-level directory in the second storage device.

[0017] The client receives a handle in the second storage device corresponding to the first-level directory, which is used to respond to the reload request;

[0018] The client determines the handle of the i-th level directory included in the first request message in the second storage device based on the handle of the first level directory corresponding to the second storage device.

[0019] The client requests access to the data corresponding to the i-th level directory included in the first request message from the second storage device based on the handle in the second storage device corresponding to the i-th level directory included in the first request message.

[0020] Based on the above design, the client can detect the change of handle when business data is migrated between storage devices and business cutover is performed. The client and the second storage device work together to complete the handle update from the root directory to the directory to be accessed. The client does not need to remount to the target storage device, which can keep the client's business uninterrupted and improve the user experience.

[0021] Secondly, embodiments of this application provide a storage access method, including:

[0022] After the data corresponding to at least one level directory in the target directory structure in the first storage device is migrated to the second storage device, the second storage device receives a first request message from the client. The first request message is used to request access to the data corresponding to the i-th level directory in the target directory structure. The first request message includes the handle of the i-th level directory in the first storage device; i is a positive integer greater than 1.

[0023] When the handle of the i-th level directory in the first storage device does not match the handle of the i-th level directory in the second storage device, the second storage device sends an access error message to the client in response to the first request message.

[0024] The second storage device receives a second request message from the client. The second request message is used to request access to the handle of the i-th level directory in the second storage device. The second request message includes the directory name of the i-th level directory and the handle of the (i-1)-th level directory in the first storage device.

[0025] When the handle of the (i-1)th level directory in the first storage device matches the handle of the (i-1)th level directory in the second storage device, the second storage device sends the handle of the i-th level directory in the second storage device back to the client.

[0026] The second storage device returns the data corresponding to the i-th level directory to the client based on the updated first request message sent by the client. The updated first request message includes the handle of the i-th level directory in the second storage device.

[0027] Thirdly, embodiments of this application provide a storage access system, including a client, a first storage device, and a second storage device;

[0028] The client is configured to send a first request message to the second storage device after the data corresponding to at least one level directory in the target directory structure in the first storage device has been migrated to the second storage device. The first request message is used to request access to the data corresponding to the i-th level directory in the target directory structure. The first request message includes the handle of the i-th level directory in the first storage device; where i is a positive integer greater than 1.

[0029] The second storage device is configured to, when the handle of the i-th level directory corresponding to the first storage device does not match the handle of the i-th level directory corresponding to the second storage device, provide the client with access error information in response to the first request message; the client is further configured to send a second request message to the second storage device, the second request message being used to request access to the handle of the i-th level directory corresponding to the second storage device, the second request message including the directory name of the i-th level directory and the handle of the (i-1)-th level directory corresponding to the first storage device;

[0030] The second storage device is further configured to, when the handle of the (i-1)th level directory corresponding to the first storage device matches the handle of the (i-1)th level directory corresponding to the second storage device, return the handle of the i-th level directory corresponding to the second storage device to the client;

[0031] The client is further configured to send an updated first request message to the second storage device, wherein the updated first request message includes the handle of the i-th level directory in the second storage device;

[0032] The second storage device is further configured to feed back the data corresponding to the i-th level directory to the client based on the updated first request message sent by the client.

[0033] In one possible design, when i is greater than 2, the client is further configured to:

[0034] Repeat the following process until the correct handle to be accessed is received from the second storage device: If an access error message is received from the second storage device in response to the second request message, then an updated second request message is sent to the second storage device. In the updated second request message, the value of i is changed to i-1 compared to the previous second request message.

[0035] Based on the correct handle received from the second storage device, determine the handle in the second storage device corresponding to the i-th level directory included in the first request message;

[0036] Based on the handle in the second storage device corresponding to the i-th level directory included in the first request message, a request is made to the second storage device to access the data corresponding to the i-th level directory included in the first request message.

[0037] In one possible design, when i equals 2, the second storage device is further configured to send an access error message to the client in response to the second request message when the handle of the first-level directory included in the second request message corresponding to the first storage device does not match the handle of the first-level directory corresponding to the second storage device.

[0038] The client is also configured to initiate a reload request for the target directory structure to the second storage device;

[0039] The second storage device is also configured to respond to the reload request by sending a handle to the client in the second storage device corresponding to the first-level directory;

[0040] The client is further configured to determine, based on the handle of the first-level directory in the second storage device, the handle of the first-level directory in the second storage device; and to request access to the data corresponding to the first-level directory in the first request message from the second storage device based on the handle of the first-level directory in the second storage device.

[0041] Fourthly, embodiments of this application provide a computing device cluster, including at least one computing device, the computing device including a processor and a memory; wherein, the memory of the at least one computing device is used to store computer execution instructions; the processor of the at least one computing device is used to execute the computer execution instructions to cause the computing device cluster to perform the method as described in the first aspect and any possible design of the first aspect, or to perform the method as described in the second aspect, or to perform the method as described in the third aspect and any possible design of the third aspect.

[0042] Fifthly, embodiments of this application provide a computer-readable storage medium comprising computer program instructions that, when executed by a computing device cluster, cause the computing device cluster to perform the method as described in the first aspect and any possible design of the first aspect, or to perform the method as described in the second aspect, or to perform the method as described in the third aspect and any possible design of the third aspect.

[0043] In a sixth aspect, embodiments of this application provide a computer program product comprising instructions that, when executed by a computing device cluster, cause the computing device cluster to perform the method as described in the first aspect and any possible design of the first aspect, or to perform the method as described in the second aspect, or to perform the method as described in the third aspect and any possible design of the third aspect.

[0044] The effects of the solutions provided in any of the second to sixth aspects above can be referenced in the corresponding descriptions in the first aspect. Attached Figure Description

[0045] Figure 1A This application provides a schematic diagram of the architecture of a storage access system.

[0046] Figure 1B This is a schematic diagram of a directory structure provided in an embodiment of this application;

[0047] Figure 2 This is a schematic diagram of the architecture of another storage access system provided in an embodiment of this application;

[0048] Figure 3 This is a schematic diagram illustrating a data migration scenario provided in an embodiment of this application.

[0049] Figure 4 One of the schematic diagrams of handle updating provided in the embodiments of this application;

[0050] Figure 5One of the schematic diagrams of handle updating provided in the embodiments of this application;

[0051] Figure 6 One of the schematic diagrams of handle updating provided in the embodiments of this application;

[0052] Figure 7 A schematic flowchart illustrating a storage access method provided in an embodiment of this application;

[0053] Figure 8 This is a schematic diagram of the structure of a computer device cluster provided in an embodiment of this application. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0055] In the embodiments of this application, at least one (item, wheel) refers to one (item, wheel) or more (items, wheels). More than one (item, wheel) refers to two (items, wheels) or more than two (items, wheels). "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, it should be understood that although the terms "first," "second," etc., may be used to describe objects in the embodiments of this application, these objects should not be limited to these terms. These terms are only used to distinguish the objects from each other.

[0056] The terms "comprising" and "having," and any variations thereof, used in the following description of embodiments of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. It should be noted that in embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any method or design described as "exemplary" or "for example" in embodiments of this application should not be construed as preferred or advantageous over other methods or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0057] This application relates to data storage technology, where client business data can be remotely stored in one or more storage devices, and the client can access the business data in the storage devices via a network. For example... Figure 1AThis illustration shows a storage access system 1000, including a client 110 and at least one storage device 120.

[0058] Specifically, both the client and the storage device can be implemented in software or hardware. For example, the following section will describe the implementation of the client. Similarly, the implementation of the storage device can refer to the client implementation.

[0059] When implemented in software, the client can be an application or code block running on a computing device. The computing device can be at least one of a physical host (or physical machine), a virtual machine, or a container. Furthermore, there can be one or more computing devices. For example, the client can be an application running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines used to run the application can be distributed within the same availability zone (AZ) or in different AZs. Similarly, the multiple hosts / virtual machines / containers used to run the application can be distributed within the same region or in different regions. Typically, a region can include multiple AZs. Likewise, the multiple hosts / virtual machines used to run the application can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a region can include multiple VPCs, and a VPC can include multiple AZs.

[0060] When implemented in hardware, in one possible implementation, the client may include at least one computing device. These computing devices can be distributed within the same Availability Zone (AZ) or in different AZs; alternatively, they can be distributed within the same region or in different regions; or they can be distributed within the same Virtual Private Cloud (VPC) or in multiple VPCs. In another possible implementation, the client can be a device implemented using an application-specific integrated circuit (ASIC) and / or a programmable logic device (PLD). The PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0061] In one optional implementation, the storage device can employ a file system, storing business data in files according to a directory structure. This directory structure, also known as a directory tree or file directory path, includes multiple levels of directories or directory nodes. The first-level directory is called the root directory, and at least one level between the first and last-level directories is called an intermediate directory. The last-level directory can be a specific file or the final directory. Based on this directory structure, a pathname can be used to locate a file in the last-level directory. For example, starting from the root directory, passing through all intermediate directories, and reaching the file corresponding to the last level, the pathname of that file can be formed. For adjacent directories, the parent directory is the parent directory of the next directory, and the next directory is a child directory of the parent directory. In terms of format, adjacent directories are separated by a backslash "\", which can also be understood as a path separator.

[0062] As an example, Figure 1B The diagram illustrates a directory structure in a storage device: Fs1\Dir1\File1. In this directory structure, Fs1 is the first-level directory, also known as the root directory; Dir1 is the second-level directory, also known as an intermediate directory; and File1 is the third-level directory, the final level directory. File1 can be a file. Figure 1B As shown, Fs1's next-level directory is Dir1, and Dir1's next-level directory is File1.

[0063] In one optional implementation, a handle is configured for each directory level in the storage device. The handle of a specific directory level is the unique identifier for locating or opening that directory within the storage device. Clients can access or read data from a directory level based on its handle in the storage device. If the directory level is a file, the handle can also be described as a file handle, which is the unique identifier for the file. As an example, Figure 1B It also illustrates how the client reads data from File1 from the storage device based on File1's file handle (e.g., denoted as fh_v1_file1). Furthermore, it's understandable that there's a relationship between the handle and the storage device; the configuration of a handle used to access the same directory might not be exactly the same on different storage devices. For example, the handle for accessing File1 might be fh_v1_file1 on storage device 1, but fh_v1_file1' on storage device 2.

[0064] Client-side business data can be migrated between storage devices. Before migration, the storage device where the client's business data resides can be called the source storage device, and after migration, it can be called the target storage device. Examples of possible migration scenarios include: the remaining capacity of the source storage device is less than a first threshold; or, the remaining capacity of the target storage device is greater than a second threshold, optionally, the second threshold is greater than or equal to the first threshold; or, the remaining capacity of the target storage device is greater than the remaining capacity of the source storage device; or, the client's business data needs to be migrated from one operator's storage device to another operator's storage device, meaning the source and target storage devices belong to different operators.

[0065] Figure 2 Taking the first storage device as the source storage device and the second storage device as the target storage device as an example, this paper illustrates three migration schemes for migrating the business data of the client 110 stored in the first storage device 121 (such as the data in the aforementioned directory structure Fs1\Dir1\File1) to the second storage device 122.

[0066] The first migration scheme involves the client 110 or the computing device where it resides controlling the data migration. For example, the client 110 or its computing device can use tools like Robocopy or rsync to configure the source and destination addresses for the migration, and then initiate the migration. The source address can be the Internet Protocol (IP) address of the first storage device 121, and the destination address can be the IP address of the second storage device 122. As an example, Figure 2(a) illustrates the process by which client 110 configures the source and destination addresses to migrate data in the directory structure Fs1\Dir1\File1 from the first storage device 121 to the second storage device 122.

[0067] The second migration option involves deploying a third-party migration server to control the data migration. For example, the third-party migration server can use tools like Robocopy or rsync, configure the source and destination addresses for the migration, and then initiate the migration. The source address can be the Internet Protocol (IP) address of the first storage device 121, and the destination address can be the IP address of the second storage device 122. As an example, Figure 2 (b) illustrates the process of configuring the source and destination addresses of the third-party migration server 130 to migrate the data of the directory structure Fs1\Dir1\File1 from the first storage device 121 to the second storage device 122.

[0068] The third migration scheme: The second storage device 122 can directly copy the client 110's business data from the first storage device 121, such as the data in the aforementioned directory structure Fs1\Dir1\File1.

[0069] It is understandable that the handles of a directory or file at a certain level within the same directory structure (e.g., Fs1\Dir1\File1) may be the same or different in the first storage device 121 and the second storage device 122. Optionally, the handle of a directory or file in the first storage device 121 can be simply referred to as the source storage handle, and the handle of a directory or file in the second storage device 122 can be simply referred to as the target storage handle. The source storage handle and the target storage handle corresponding to the same directory or file may be the same or different. Furthermore, optionally, the first and second migration schemes described above can also be uniformly summarized as host-based migration schemes. The third migration scheme can also be described as a serverless migration scheme.

[0070] After client 110's business data is migrated from the first storage device 121 to the second storage device 122, client 110 needs to perform a service cutover, that is, switch the client 110's service mount from the first storage device 121 to the second storage device 122. Before the service cutover, the client can access files or directories in the first storage device 121 using the source storage handle. During the service cutover, client 110 can access files or directories in the second storage device 122 using the source storage handle. Correspondingly, if the second storage device 122 cannot recognize the source storage handle, it can notify client 110 of an access error. Then, client 110 and the second storage device 122 can cooperate to update the source storage handle to the target storage handle, and the client can use the target storage handle to resume access to the business data in the second storage device 122. In this design, the client can perceive the handle change during the service cutover, without needing the client to remount to the target storage device, thus maintaining uninterrupted client services and improving user experience.

[0071] The solutions provided in this application can also be applied to NAS file system migration scenarios. For example... Figure 3 In this scenario, the first storage device can be a source NAS, and the second storage device can be a target NAS. When storing client business data on a file system hosted on the NAS according to the Network File System (NFS) protocol, the file system hosted on the NAS can also be understood as NFS, and the aforementioned client can be called an NFS client. The NFS protocol allows client business data to be stored in a directory-structured format on the network, sharing directories and files with other devices (such as other clients or application servers). The NFS client can also access its own business data over the network according to the directory structure. Optionally, the source NAS and the target NAS can belong to the same or different operators.

[0072] NAS file system migration solutions can be divided into two types: host-based migration solutions and serverless migration solutions. In host-based migration solutions, the computing device hosting the third-party migration server, NFS client, or NAS client can control the migration of data or file systems from the source NAS to the target NAS. As an example, Figure 3 (a) illustrates the process of configuring the source address (such as the IP address of the source NAS) and the destination address (such as the IP address of the target NAS) on the NAS client to migrate data or file systems from the source NAS to the target NAS. Figure 3(b) illustrates how a third-party migration server configures the source address (e.g., the IP address of the source NAS) and the destination address (e.g., the IP address of the target NAS) to migrate data or file systems from the source NAS to the target NAS. Furthermore, after confirming the migration of data or file systems from the source NAS to the target NAS, the client or the third-party migration server can perform a service cutover, switching the NFS client's services from the source NAS to the target NAS. The target NAS and the NFS client then work together to update the file handles. In a service-free migration solution: the target NAS can copy data or file systems from the source NAS. Then, during the service cutover, the client's services switch from the source NAS to the target NAS, and the target NAS and the NFS client work together to update the file handles.

[0073] To facilitate implementation, the following example illustrates the scheme for updating the handle by the client and the second storage device in cooperation during service cutover, using the migration of data from the directory structure Fs1\Dir1\File1 from the first storage device to the second storage device.

[0074] Example 1

[0075] When a client accesses data in Dir1 from a second storage device, if the source and target storage handles of Fs1 in the directory structure Fs1\Dir1\File1 are the same, but the source and target storage handles of Dir1 are different, the client and the second storage device need to cooperate to update the handle of Dir1.

[0076] Figure 4 The following table 1 illustrates the process by which the client and the second storage device work together to update the handle of Dir1 from the source storage handle in the first storage device to the target storage handle in the second storage device.

[0077] Table 1

[0078] Fs1 roofh_v1 roofh_v1 Dir1 fh_v1_dir1 fh_hw_dir1 File1 fh_v1_file1

[0079] Figure 4 The illustrated process mainly includes the following steps:

[0080] S401, the client requests access to the data in Dir1 from the second storage device based on the source storage handle fh_v1_dir1 of Dir1; correspondingly, since the source storage handle and the target storage handle of Dir1 are different, the second storage device cannot recognize fh_v1_dir1 and can send an access error message to the client.

[0081] For example, the client sends a Read message containing fh_v1_dir1 to the second storage device to access the data in Dir1 on the second storage device; the second storage device sends a Read_res(STALE_UNKNOWN_FH) message back to the client, indicating that the client's access to the data in Dir1 has failed. STALE_UNKNOWN_FH can be understood as representing an error code.

[0082] S402, the client requests the target storage handle of Dir1 from the second storage device based on the source storage handle roofh_v1 of Fs1 and the directory name Dir1.

[0083] For example, the client sends a lookup message containing roofh_v1 and Dir1 to the second storage device, i.e., a lookup of (roofh_v1, Dir1).

[0084] S403, since the source storage handle and target storage handle of Fs1 are the same, that is, the second storage device can recognize roofh_v1, the query of S402 is successful, and the second storage device can send the target storage handle fh_hw_dir1 of Dir1 back to the client.

[0085] For example, the second storage device sends a query _res(fh_hw_dir1) to the client. Based on this, the client can save the target storage handle fh_hw_dir1 of Dir1. Optionally, the client can also delete the source storage handle fh_v1_dir1 of Dir1.

[0086] S404, the client can continue to access the data in Dir1 in the second storage device according to the target storage handle fh_hw_dir1 of Dir1; correspondingly, the second storage device can send the data of Dir1 back to the client.

[0087] For example, the client can send a read (fh_hw_dir1) message to the second storage device, and the second storage device will then send a read response message to the client containing the data of the aforementioned Dir1, such as read_res(data of Dir1).

[0088] Furthermore, suppose a client subsequently wishes to access file File1 in the second storage device. First, the client can send a read request (fh_v1_file1) to the second storage device; the second storage device will then send a read request (STALE_UNKNOWN_FH) to the client. Then, the client can send a query request (fh_hw_dir1 / File1) to the second storage device, and the second storage device will send a query request (fh_hw_file1) to the client.

[0089] Example 2

[0090] When a client accesses data for File1 on a second storage device, and the source and target storage handles of Dir1 and File1 on the directory structure Fs1\Dir1\File1 are different, the client and the second storage device cooperate to update the handles of Dir1 and File1.

[0091] Figure 5 Table 2 below illustrates the process by which the client and the second storage device work together to update the handles of Dir1 and File1 from the source storage handle in the first storage device to the target storage handle in the second storage device.

[0092] Table 2

[0093] Fs1 roofh_v1 roofh_v1 Dir1 fh_v1_dir1 fh_hw_dir1 File1 fh_v1_file1 fh_hw_file1

[0094] Figure 5 The illustrated process mainly includes the following steps:

[0095] S501, the client requests access to the data of File1 from the second storage device based on the source storage handle fh_v1_file1 of File1; correspondingly, since the source storage handle and the target storage handle of File1 are different, the second storage device cannot recognize fh_v1_file1 and can send an access error message to the client.

[0096] For example, the client sends a Read message containing fh_v1_file1 to the second storage device to access the data of File1 in the second storage device; the second storage device returns a Read_res(STALE_UNKNOWN_FH) response to the client, indicating that the client's access to the data of File1 has failed. STALE_UNKNOWN_FH can be understood as representing an error code.

[0097] S502, the client requests the second storage device to query the target storage handle of File1 based on the source storage handle fh_v1_dir1 of Dir1 and the directory name File1; correspondingly, since the source storage handle and target storage handle of Dir1 are different, the second storage device cannot recognize fh_v1_dir1 and can report a query error to the client.

[0098] For example, the client sends a lookup message containing fh_v1_dir1 and File1 to the second storage device, i.e., a lookup of (fh_v1_dir1, File1); the second storage device sends a lookup message _res(STALE_UNKNOWN_FH) to the client, indicating that the client's lookup of the target storage handle of File1 has failed.

[0099] S503, the client requests the target storage handle of Dir1 from the second storage device based on the source storage handle roofh_v1 of Fs1 and the name of Dir1.

[0100] For example, the client sends a lookup message containing roofh_v1 and Dir1 to the second storage device, i.e., a lookup of (roofh_v1, Dir1).

[0101] S504, since the source storage handle and target storage handle of Fs1 are the same, that is, the second storage device can recognize roofh_v1, the query of S503 is successful, and the second storage device can send the target storage handle fh_hw_dir1 of Dir1 back to the client.

[0102] For example, the second storage device sends a query _res(fh_hw_dir1) to the client. Based on this, the client can save the target storage handle fh_hw_dir1 of Dir1. Optionally, the client can also delete the source storage handle fh_v1_dir1 of Dir1.

[0103] S505, the client requests the second storage device to query the target storage handle of File1 based on the target storage handle fh_hw_dir1 of Dir1 and the directory name File1; correspondingly, the second storage device can return the target storage handle fh_hw_file1 of File1.

[0104] For example, the client sends a lookup message containing fh_hw_dir1 and File1 to the second storage device, i.e., lookup (fh_hw_dir1, File1), and the second storage device sends a lookup response message containing fh_hw_file1 to the client, such as lookup_res(fh_hw_file1).

[0105] Based on this, the client can save the target storage handle fh_hw_file1 for File1. Optionally, the client can also delete the source storage handle fh_v1_file1 for File1.

[0106] Furthermore, the client can continue accessing the data of File1 in the second storage device according to the target storage handle fh_hw_file1 of File1. Optionally, the client can access part or all of the data in File1.

[0107] When accessing a portion of data in File1, you need to specify the location of that portion of data within File1, for example... Figure 5 The diagram illustrates S506:

[0108] S506, the client sends a read message to the second storage device for accessing a portion of the data in File1, for example, sending read(fh_hw_file1, s, l), where s represents the starting byte to be read in file fh_hw_file1, and l represents the length to be read in file fh_hw_file1. Correspondingly, the second storage device sends a read response message to the client containing the aforementioned portion of the data in File1, for example, read_res(partial data in File1).

[0109] Example 3

[0110] When a client accesses data for File1 on a second storage device, and the source and target storage handles of each level of the directory structure Fs1\Dir1\File1 are different, the client and the second storage device need to cooperate to update the handles of Fs1, Dir1, and File1.

[0111] Figure 6 Table 3 below illustrates the process by which the client and the second storage device work together to update the handles of Fs1, Dir1, and File1 from the source storage handle in the first storage device to the target storage handle in the second storage device.

[0112] Table 3

[0113] Fs1 roofh_v1 roofh_hw Dir1 fh_v1_dir1 fh_hw_dir1 File1 fh_v1_file1 fh_hw_file1

[0114] Figure 6 The illustrated process mainly includes the following steps:

[0115] S601, the client requests access to the data of File1 from the second storage device based on the source storage handle fh_v1_file1 of File1; correspondingly, since the source storage handle and the target storage handle of File1 are different, the second storage device cannot recognize fh_v1_file1 and can send an access error message to the client.

[0116] For example, the client sends a Read message containing fh_v1_file1 to the second storage device to access the data of File1 in the second storage device; the second storage device returns a Read_res(STALE_UNKNOWN_FH) response to the client, indicating that the client's access to the data of File1 has failed. STALE_UNKNOWN_FH can be understood as representing an error code.

[0117] S602, the client requests the second storage device to query the target storage handle of File1 based on the source storage handle fh_v1_dir1 of Dir1 and the directory name File1; correspondingly, since the source storage handle and target storage handle of Dir1 are different, the second storage device cannot recognize fh_v1_dir1 and can report a query error to the client.

[0118] For example, the client sends a lookup message containing fh_v1_dir1 and File1 to the second storage device, i.e., a lookup of (fh_v1_dir1, File1); the second storage device sends a lookup message _res(STALE_UNKNOWN_FH) to the client, indicating that the client's lookup of the target storage handle of File1 has failed.

[0119] S603, the client requests the second storage device to query the target storage handle of Dir1 based on the source storage handle roofh_v1 of Fs1 and the directory name Dir1; correspondingly, since the source storage handle and the target storage handle of Fs1 are different, the second storage device cannot recognize roofh_v1 and can report a query error to the client.

[0120] For example, the client sends a lookup message containing roofh_v1 and Dir1 to the second storage device, i.e., a lookup of (roofh_v1, Dir1); the second storage device sends a lookup message _res(STALE_UNKNOWN_FH) to the client, indicating that the client's lookup of the target storage handle of Dir1 has failed.

[0121] Based on the above S601 to S603, the client received three error codes STALE_UNKNOWN_FH, indicating that the source and target storage handles of each level of the directory structure Fs1\Dir1\File1 are different. Therefore, the client can execute S604: The client initiates a reload (mount) of the directory structure Fs1\Dir1\File1 to the second storage device.

[0122] Accordingly, the second storage device and the client cooperate to update the handles of Fs1, Dir1, and File1 from Fs1 to File1 in the directory structure Fs1\Dir1\File1. For details, please refer to S605 to S607.

[0123] S605, the second storage device sends a load response message containing `roofh_hw`, such as `load_res(roofh_hw)`, to the client to indicate that the target storage handle of Fs1 is `roofh_hw`; correspondingly, the client can save the target storage handle `roofh_hw` of Fs1. Optionally, the client can also delete the source storage handle `roofh_v1` of Fs1.

[0124] S606, the client requests the second storage device to query the target storage handle of Dir1 based on the target storage handle of Fs1 (roofh_hw) and the directory name Dir1; correspondingly, the second storage device can return the target storage handle of Dir1 (fh_hw_dir1).

[0125] For example, the client sends a lookup message containing roofh_hw and Dir1 to the second storage device, i.e., lookup (roofh_hw, Dir1), and the second storage device sends a lookup response message containing fh_hw_dir1 to the client, such as lookup_res(fh_hw_dir1).

[0126] Based on this, the client can save the target storage handle fh_hw_dir1 of Dir1. Optionally, the client can also delete the source storage handle fh_v1_dir1 of Dir1.

[0127] S607, the client requests the second storage device to query the target storage handle of File1 based on the target storage handle fh_hw_dir1 of Dir1 and the directory name File1; correspondingly, the second storage device can return the target storage handle fh_hw_file1 of File1.

[0128] For example, the client sends a lookup message containing fh_hw_dir1 and File1 to the second storage device, i.e., lookup (fh_hw_dir1, File1), and the second storage device sends a lookup response message containing fh_hw_file1 to the client, such as lookup_res(fh_hw_file1).

[0129] Based on this, the client can save the target storage handle fh_hw_file1 for File1. Optionally, the client can also delete the source storage handle fh_v1_file1 for File1.

[0130] Furthermore, the client can continue accessing the data of File1 in the second storage device according to the target storage handle fh_hw_file1 of File1. Optionally, the client can access part or all of the data in File1.

[0131] When accessing a portion of data in File1, you need to specify the location of that portion of data within File1, for example... Figure 6 The image shows S608:

[0132] S608, the client sends a read message to the second storage device for accessing a portion of the data in File1, for example, sending read(fh_hw_file1, s, l), where s represents the starting byte to be read in file fh_hw_file1, and l represents the length to be read in file fh_hw_file1. Correspondingly, the second storage device sends a read response message to the client containing the aforementioned portion of the data in File1, for example, read_res(partial data in File1).

[0133] Based on Examples 1-3 above, this application also provides a storage access method, such as... Figure 7 As illustrated, this method mainly includes the following steps.

[0134] S700, the client's business data in the first storage device is migrated to the second storage device.

[0135] The business data in the first storage device includes data corresponding to each level of the target directory structure described below. It is understood that the target directory structure includes at least one level of directory, i.e., one or more levels of directories.

[0136] In one alternative implementation, the migration of business data from the first storage device to the second storage device can be performed by the client or a third-party migration server. In another alternative implementation, the second storage device can copy the business data from the first storage device to itself.

[0137] In a scenario where the client expects to access or read data from the i-th level directory of the target directory structure after the migration of business data is completed, the client can access the data from the i-th level directory from the first storage device before the business cutover is performed; during the business cutover, the client can access the data from the i-th level directory from the second storage device. For example, the client can execute the following S701 to S703.

[0138] S701, the client sends a first request message to the second storage device.

[0139] The first request message is used to access the data corresponding to the i-th level directory in the target directory structure, where i is a positive integer greater than 1. In other words, the first message is used to access the data corresponding to the intermediate directories, the final directory, or the file in the target directory structure.

[0140] In one possible implementation, the first request message includes a handle to the i-th level directory in the first storage device, or it can be described as including a source storage handle to the i-th level directory. Optionally, the first request message can be used to read part or all of the data in a file; when the first request message is used to read part of the data in a file, the first request message may also include the position information of that part of the data in the file, such as the starting byte and the length of the data to be read.

[0141] For example, the first request message can be implemented as a Read message, in the format of Read(the handle of the i-th level directory in the first storage device) or Read(the handle of the i-th level directory in the first storage device, the starting read byte, and the read length).

[0142] S702, the second storage device sends an access error message to the client in response to the first request message.

[0143] For example, if the handle in the first storage device corresponding to the i-th level directory included in the first request message does not match the handle in the second storage device corresponding to the i-th level directory, an access error message is sent to the client. It can be understood that this access error message indicates that the second storage device cannot recognize the handle in the first storage device corresponding to the i-th level directory included in the first request message, or that the access error message indicates that the client encountered an error accessing data in the second storage device using the source storage handle.

[0144] Optionally, the access error message can be implemented using an error code (such as STALE_UNKNOWN_FH). If the first message is implemented using a Read message, the second storage device can send a Read response (Read_response, Read_res) message to the client, which includes STALE_UNKNOWN_FH.

[0145] Alternatively, the access in S701 to S702 can also be described as reading.

[0146] S703, the client sends a second request message to the second storage device.

[0147] The second request message is used to request access to the handle in the second storage device corresponding to the i-th level directory included in the aforementioned first request message. The second request message includes the directory name of the i-th level directory included in the first request message, and the handle in the first storage device corresponding to the (i-1)-th level directory. Alternatively, the access in S703 can also be described as a query.

[0148] For example, the second request message can be implemented as a lookup message, with the format lookup(handle of the (i-1)th level directory in the first storage device, directory name of the i-th level directory).

[0149] Accordingly, the second storage device can respond to the client based on whether the handle of the (i-1)th level directory in the first storage device matches the handle of the (i-1)th level directory in the second storage device, depending on the situation. The interaction between the client and the second storage device under different circumstances is described in detail below.

[0150] Scenario 1: The handle of the (i-1)th level directory in the first storage device matches the handle of the (i-1)th level directory in the second storage device, meaning the second storage device can recognize the handle of the (i-1)th level directory in the first storage device. In this case, after executing S701 to S703, S704 can be executed to allow the client to obtain the handle of the i-th level directory in the second storage device.

[0151] S704, the second storage device sends a handle to the client corresponding to the i-th level directory in the second storage device.

[0152] In scenario one above, the client can obtain the target storage handle corresponding to the access target (the i-th level directory) with a single query to the second storage device. This scenario one solution can be applied to example one mentioned above, or in other words, example one is an application example of scenario one.

[0153] Scenario 2: The handle of the (i-1)th level directory in the first storage device does not match the handle of the (i-1)th level directory in the second storage device, and i equals 2. That is, the second storage device cannot recognize the handle of the first level directory (i.e., the root directory) in the first storage device. In this case, the interaction between the client and the second storage device can be understood with reference to S705 to S708 below.

[0154] S705, the second storage device sends an access error message to the client in response to the second request message.

[0155] For example, the access error message could be lookup_res(STALE_UNKNOWN_FH).

[0156] S706, the client initiates a reload request for the target directory structure to the second storage device.

[0157] S707, the second storage device responds to the reload request and sends the handle of the first-level directory in the second storage device back to the client.

[0158] S708, the client determines the handle of the i-th level directory included in the first request message in the second storage device based on the handle of the first level directory corresponding to the second storage device.

[0159] For example, if i is 2, the client sends a lookup to the second storage device (the handle of the first-level directory in the second storage device and the directory name of the second-level directory), and the second storage device sends a lookup_res back to the client (the handle of the second-level directory in the second storage device).

[0160] Case 3: The handle of the (i-1)th level directory in the first storage device does not match the handle of the (i-1)th level directory in the second storage device, and i is greater than 2. That is, the second storage device cannot recognize the handle of the (i-1)th level directory (i.e. the root directory) in the first storage device.

[0161] In this case, the client can first repeatedly execute the following processes S709 to S710 until the first stop condition or the second stop condition is met:

[0162] S709, the client receives access error information from the second storage device in response to the second request message.

[0163] S710, the client sends an updated second request message to the second storage device. In the updated second request message, the value of i is changed to i-1 compared to the previous second request message.

[0164] (1) The first stopping condition is that the client receives the correct handle to be accessed from the second storage device. For example, during the repeated execution of S709 to S710 by the client, the value of i changes from i in the first request message to 2. If there exists a value of m for i, 2≤m<i, and the handle of the (m-1)th level directory in the first storage device matches the handle of the (m-1)th level directory in the second storage device, the second storage device can provide the client with the correct handle, that is, the handle of the m-th level directory in the second storage device.

[0165] When the result of repeatedly executing S709 to S710 satisfies the first stopping condition, such as Figure 7It can be shown that after S710, S711 can also be executed: The client determines the handle in the second storage device corresponding to the i-th level directory included in the first request message based on the correct handle fed back by the second storage device.

[0166] Assume the client receives a correct handle from the second storage device, which is the handle of the m-th level directory in the second storage device, where m is the value of i in the first request message minus 1. Based on this, the client can send a lookup to the second storage device (the handle of the m-th level directory in the second storage device and the directory name of the i-th level directory included in the first request message); correspondingly, the second storage device can send a lookup_res back to the client (the handle of the i-th level directory in the second storage device included in the first request message). For example, when the value of i in the first request message is 3, the value of m is 2.

[0167] Furthermore, it is understood that the setting of this first stopping condition can be applied to the aforementioned Example 2, or in other words, Example 2 is an application example of this first stopping condition.

[0168] (2) The second stopping condition is that the client receives an access error message from the second storage device in response to the latest second request message, and the latest second request message includes the name of the second-level directory and the handle of the first-level directory in the first storage device. Alternatively, it can be understood that the aforementioned repeated execution process is stopped based on the second stopping condition, including: repeatedly executing S709 to S710 until the second storage device determines that the handle of the first-level directory in the first storage device does not match the handle of the first-level directory in the second storage device.

[0169] When the result of the aforementioned repeated execution of S709 to S710 satisfies the second stop condition, the client and the second storage device can continue to execute the following S712 to S714 to determine the target handle in the second storage device corresponding to the i-th level directory included in the first request message.

[0170] S712, the client initiates a reload request for the target directory structure to the second storage device.

[0171] S713, the second storage device responds to the reload request and sends the handle of the first-level directory in the second storage device back to the client.

[0172] S714, the client determines the handle of the i-th level directory included in the first request message in the second storage device based on the handle of the first level directory corresponding to the second storage device.

[0173] For example, if i is 3, the client sends a lookup to the second storage device (the handle of the first-level directory in the second storage device and the directory name of the second-level directory), and the second storage device sends a lookup_res back to the client (the handle of the second-level directory in the second storage device); then, the client sends a lookup to the second storage device (the handle of the second-level directory in the second storage device and the directory name of the third-level directory), and the second storage device sends a lookup_res back to the client (the handle of the third-level directory in the second storage device).

[0174] Furthermore, it is understood that the setting of this second stopping condition can be applied to the aforementioned Example 3, or in other words, Example 3 is an application example of this second stopping condition.

[0175] Furthermore, after the client receives the target handle in the second storage device corresponding to the i-th level directory included in the first request message, i.e., after executing S704, S708, or S714, the client can also request access to the data corresponding to the i-th level directory from the second storage device based on the target handle in the second storage device corresponding to the i-th level directory. For example, after executing S704, S708, or S714, execute S715 to S716:

[0176] S715, the client sends an updated first request message to the second storage device.

[0177] The updated first request message includes a handle in the second storage device corresponding to the i-th level directory described in S701. This updated first request message is used to request access to the data corresponding to the i-th level directory. It can be understood that in this step, the client requests access to the data corresponding to the i-th level directory from the second storage device based on the handle in the second storage device corresponding to the i-th level directory.

[0178] For example, when the i-th level directory is a file, the updated first request message is Read (the i-th level directory corresponds to a handle in the second storage device) or Read (the i-th level directory corresponds to a handle in the second storage device, the starting read byte, and the read length).

[0179] S716, the second storage device responds to the updated first request message and sends the data corresponding to the i-th level directory back to the client.

[0180] Corresponding to S715, if the first request message is Read (the handle of the i-th level directory in the second storage device), then the second storage device returns all the data corresponding to the i-th level directory; if the first request message is Read (the handle of the i-th level directory in the second storage device, the starting read byte, and the read length), then the second storage device returns part of the data corresponding to the i-th level directory, and the position of this part of the data in the i-th level directory (such as a file) is determined by the starting read byte and the read length.

[0181] The storage method provided in this application embodiment enables online handle updates through the cooperation of the target storage device and the client during data migration from the source storage device to the target storage device and service cutover. The client does not need to remount the storage device, which enables dynamic takeover of services between storage devices, providing continuous application availability during migration, avoiding the impact of service interruption, and thus improving user experience.

[0182] Based on the above embodiments, this application also provides a computing device cluster. For example... Figure 8 As illustrated, the computing device cluster includes at least one computing device 100, and each computing device 100 includes a processor 104 and a memory 106.

[0183] In this computing device cluster, the memory 106 of at least one computing device 100 stores computer execution instructions, such as instructions from the same memory access system for executing the aforementioned memory access method. The processor 104 of at least one computing device 100 executes these computer execution instructions, causing the computing device cluster to execute the instructions for the memory access method. In some possible implementations, one or more computing devices 100 in the computing device cluster may also be used to execute a portion of the instructions from the memory access system for executing the memory access method. In other words, a combination of one or more computing devices 100 can jointly execute the instructions from the memory access system for executing the memory access method.

[0184] Each computing device 100 may also include a communication interface 108, through which a computing device 100 can interact with other computing devices. For example, the communication interface 108 may be a transceiver, circuit, bus, module, pin, or other type of communication interface. When the computing device 100 is a chip-type device or circuit, the communication interface 108 in the computing device 100 may also be an input / output circuit, capable of inputting information (or receiving information) and outputting information (or sending information). The processor may be an integrated processor, a microprocessor, an integrated circuit, or a logic circuit, and the processor can determine the output information based on the input information.

[0185] The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, which can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. The processor 104 may operate in conjunction with the memory 106 and the communication interface 108. This embodiment does not limit the specific connection medium between the processor 104, memory 106, and communication interface 108.

[0186] Optional, see Figure 8 The processor 104, the memory 106, and the communication interface 108 are interconnected via a bus 102. The bus 102 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0187] In the embodiments of this application, the processor may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, capable of implementing or executing the methods, steps, and logic block diagrams of the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0188] In the embodiments of this application, the memory can be non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), or it can be volatile memory, such as random-access memory (RAM). Memory is any other medium capable of carrying or storing desired program code in the form of instructions or data structures, and accessible by a computer, but is not limited thereto. The memory in the embodiments of this application can also be a circuit or any other device capable of implementing storage functions, used to store program instructions and / or data.

[0189] Furthermore, it should be noted that the memory 106 in different computing devices 100 within a computing device cluster can store different instructions. The instructions stored in the memory 106 of one computing device 100 are used to execute some functions of the storage access system. That is, the instructions stored in the memory 106 of one computing device 100 can implement some functions of a client or storage device (such as a NAS).

[0190] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any available medium. When the computer program product runs on a cluster of computing devices, it causes the cluster of computing devices to execute the aforementioned storage access method applied to a storage access system, or causes the cluster of computing devices to execute the aforementioned storage access method applied to a storage access system.

[0191] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct a cluster of computing devices to execute the aforementioned storage access method applied to a storage access system, or instruct the cluster of computing devices to execute the aforementioned storage access method applied to a storage access system.

[0192] In the embodiments of this application, examples can reference each other without logical contradictions. For example, methods and / or terms between method embodiments can reference each other, functions and / or terms between system embodiments can reference each other, and functions and / or terms between system examples and method examples can reference each other.

[0193] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A storage access method, characterized in that, include: After the data corresponding to at least one level directory in the target directory structure in the first storage device is migrated to the second storage device, the client sends a first request message to the second storage device. The first request message is used to request access to the data corresponding to the i-th level directory in the target directory structure. The first request message includes the handle of the i-th level directory in the first storage device. The i is a positive integer greater than 1; The client receives access error information from the second storage device in response to the first request message; wherein, the access error information is provided by the second storage device when the handle of the i-th level directory corresponding to the first storage device is different from the handle of the i-th level directory corresponding to the second storage device. The client sends a second request message to the second storage device. The second request message is used to request access to the handle of the i-th level directory in the second storage device. The second request message includes the directory name of the i-th level directory and the handle of the (i-1)-th level directory in the first storage device. If the client receives the handle of the i-th level directory in the second storage device from the second storage device, then it sends an updated first request message to the second storage device and receives the data corresponding to the i-th level directory from the second storage device; wherein, the handle of the i-th level directory in the second storage device is fed back by the second storage device when the handle of the (i-1)-th level directory in the first storage device is the same as the handle of the (i-1)-th level directory in the second storage device; the updated first request message includes the handle of the i-th level directory in the second storage device.

2. The method as described in claim 1, characterized in that, When i is greater than 2, it also includes: Repeat the following process until the client receives the correct handle to be accessed from the second storage device: If the client receives an access error message from the second storage device in response to the second request message, then send an updated second request message to the second storage device. In the updated second request message, the value of i is changed to i-1 compared to the previous second request message. Based on the correct handle received from the second storage device, the client determines the handle in the second storage device corresponding to the i-th level directory included in the first request message. The client requests access to the data corresponding to the i-th level directory included in the first request message from the second storage device based on the handle in the second storage device corresponding to the i-th level directory included in the first request message.

3. The method as described in claim 1, characterized in that, When i equals 2, it also includes: If the client receives an access error message from the second storage device in response to the second request message, it initiates a reload request for the target directory structure to the second storage device; wherein, the access error message in response to the second request message is a response from the second storage device when the handle of the first-level directory included in the second request message in the first storage device is different from the handle of the first-level directory in the second storage device. The client receives a handle in the second storage device corresponding to the first-level directory, which is used to respond to the reload request; The client determines the handle of the i-th level directory in the second storage device based on the handle of the first-level directory in the second storage device; The client requests access to the data corresponding to the i-th level directory from the second storage device based on the handle of the i-th level directory in the second storage device.

4. A storage access method, characterized in that, include: After the data corresponding to at least one level directory in the target directory structure in the first storage device is migrated to the second storage device, the second storage device receives a first request message from the client. The first request message is used to request access to the data corresponding to the i-th level directory in the target directory structure. The first request message includes the handle of the i-th level directory in the first storage device. The i is a positive integer greater than 1; When the handle of the i-th level directory in the first storage device is different from the handle of the i-th level directory in the second storage device, the second storage device sends an access error message to the client in response to the first request message. The second storage device receives a second request message from the client. The second request message is used to request access to the handle of the i-th level directory in the second storage device. The second request message includes the directory name of the i-th level directory and the handle of the (i-1)-th level directory in the first storage device. When the handle of the (i-1)th level directory in the first storage device is the same as the handle of the (i-1)th level directory in the second storage device, the second storage device sends the handle of the i-th level directory in the second storage device back to the client. The second storage device returns the data corresponding to the i-th level directory to the client based on the updated first request message sent by the client. The updated first request message includes the handle of the i-th level directory in the second storage device.

5. A storage access system, characterized in that, Includes a client, a first storage device, and a second storage device; The client is configured to send a first request message to the second storage device after the data corresponding to at least one level directory in the target directory structure in the first storage device has been migrated to the second storage device. The first request message is used to request access to the data corresponding to the i-th level directory in the target directory structure. The first request message includes the handle of the i-th level directory in the first storage device. The i is a positive integer greater than 1; The second storage device is configured to send an access error message to the client in response to the first request message when the handle of the i-th level directory in the first storage device is different from the handle of the i-th level directory in the second storage device. The client is further configured to send a second request message to the second storage device. The second request message is configured to request access to the handle of the i-th level directory in the second storage device. The second request message includes the directory name of the i-th level directory and the handle of the (i-1)-th level directory in the first storage device. The second storage device is further configured to, when the handle of the (i-1)th level directory in the first storage device is the same as the handle of the (i-1)th level directory in the second storage device, feed back the handle of the i-th level directory in the second storage device to the client; The client is further configured to send an updated first request message to the second storage device, wherein the updated first request message includes the handle of the i-th level directory in the second storage device; The second storage device is further configured to feed back the data corresponding to the i-th level directory to the client based on the updated first request message sent by the client.

6. The system as described in claim 5, characterized in that, When i is greater than 2, the client is further configured to: Repeat the following process until the correct handle to be accessed is received from the second storage device: If an access error message is received from the second storage device in response to the second request message, then an updated second request message is sent to the second storage device. In the updated second request message, the value of i is changed to i-1 compared to the previous second request message. Based on the correct handle received from the second storage device, determine the handle in the second storage device corresponding to the i-th level directory included in the first request message; Based on the handle in the second storage device corresponding to the i-th level directory included in the first request message, a request is made to the second storage device to access the data corresponding to the i-th level directory included in the first request message.

7. The system as described in claim 5, characterized in that, When i equals 2, the second storage device is further configured to, when the handle of the first-level directory included in the second request message corresponding to the first storage device is different from the handle of the first-level directory corresponding to the second storage device, send an access error message to the client to respond to the second request message. The client is also configured to initiate a reload request for the target directory structure to the second storage device; The second storage device is also configured to respond to the reload request by sending a handle to the client in the second storage device corresponding to the first-level directory; The client is further configured to determine the handle of the i-th level directory corresponding to the second storage device based on the handle of the first level directory corresponding to the second storage device; And based on the handle of the i-th level directory in the second storage device, request access to the data corresponding to the i-th level directory from the second storage device.

8. A computing device cluster, characterized in that, It includes at least one computing device, the computing device including a processor and a memory; The memory of the at least one computing device is used to store computer-executed instructions; The processor of the at least one computing device is configured to execute the computer execution instructions to cause the computing device cluster to perform the method as described in any one of claims 1-3, or to perform the method as described in claim 4.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer program instructions that, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the method as described in any one of claims 1-3, or to perform the method as described in claim 4.

10. A computer program product, characterized in that, The computer program product includes instructions that, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the method as described in any one of claims 1-3, or to perform the method as described in claim 4.

Images