Request processing method and device based on object storage, equipment and storage medium

Abstract

The embodiment of the invention provides an object storage-based request processing method and device for an object access request, equipment and a storage medium, and relates to the technical field of object storage. The method comprises the following steps: in response to a restart instruction of a user mode daemon process, loading a pre-stored object node file and an object name file from a local storage to the user mode daemon process; according to the object node file, reestablishing a first mapping relationship between the object node identifier and the object node information, and according to the object node file and the object name file, reestablishing a second mapping relationship between the directory node identifier of the parent directory where the object is located, the object name information and the object node information; and processing an object access request sent by the kernel module based on the first mapping relation and the second mapping relation through the restarted user mode daemon process. According to the method, the object access request can be automatically recovered after the user state daemon process is restarted, so that the user experience is improved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure relate to the technical field of object storage, and in particular, to an object storage-based request processing method and device, equipment and a storage medium. BACKGROUND

[0002] Object storage is a technology for storing and managing data in an unstructured format. Among them, object storage cloud services are widely used in various industries due to their advantages of supporting massive storage, strong scalability, high reliability, low cost, etc.

[0003] In related technologies, objects in an object storage cloud service can be accessed through a FUSE (Filesystem in Userspace) mechanism. In the user space file system, many operations need to access objects through object node identifiers, while object storage cloud services need to access objects through object paths. Therefore, in order to access objects in the object storage cloud service through the user space file system, a mapping relationship table needs to be created in the user space file system for access semantic conversion between the user space file system and the object storage cloud service.

[0004] However, the inventors have found that at least the following technical problems exist in the related art: In a high-load scenario, the user-mode daemon is prone to crash. After crashing, the file information in the kernel is inconsistent with the file information of the user-mode daemon, which causes the object access request to be unable to automatically recover. At this time, the computing task needs to be remounted and restarted, thereby wasting computing resources and time and causing poor user experience. SUMMARY

[0005] Embodiments of the present disclosure provide an object storage-based request processing method and device, equipment and a storage medium, which can automatically recover object access requests and improve user experience.

[0006] In a first aspect, the embodiments of the present disclosure provide an object storage-based request processing method, comprising:

[0007] In response to a restart instruction of a user-mode daemon, loading a pre-stored object node file and an object name file from a local storage to the user-mode daemon; wherein the object node file is used to maintain object node information, and the object name file is used to maintain object name information;

[0008] According to the object node file, re-establishing a first mapping relationship between object node identifiers and object node information, and according to the object node file and the object name file, re-establishing a second mapping relationship between directory node identifiers of parent directories of objects, object name information and object node information;

[0009] The processing unit processes an object access request sent by a kernel module based on the first mapping relationship and the second mapping relationship through the restarted user-mode daemon process.

[0010] In a second aspect, the embodiments of the present disclosure provide an object storage-based request processing apparatus, which comprises:

[0011] A loading unit is configured to load a pre-stored object node file and an object name file from a local storage to a user-mode daemon process in response to a restart instruction of the user-mode daemon process, wherein the object node file is used to maintain object node information, and the object name file is used to maintain object name information.

[0012] A mapping unit is configured to re-establish a first mapping relationship between an object node identifier and object node information according to the object node file, and re-establish a second mapping relationship between a directory node identifier of a parent directory where an object is located, object name information and object node information according to the object node file and the object name file.

[0013] A processing unit is configured to process an object access request sent by a kernel module based on the first mapping relationship and the second mapping relationship through the restarted user-mode daemon process.

[0014] In a third aspect, the embodiments of the present disclosure provide an electronic device, which comprises a processor and a memory.

[0015] The memory stores computer-executable instructions.

[0016] The processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the object storage-based request processing method according to the first aspect and various possible designs of the first aspect.

[0017] In a fourth aspect, the embodiments of the present disclosure provide a computer-readable storage medium, which stores computer-executable instructions, and when a processor executes the computer-executable instructions, the object storage-based request processing method according to the first aspect and various possible designs of the first aspect is implemented.

[0018] In a fifth aspect, the embodiments of the present disclosure provide a computer program product, which comprises a computer program, and when a processor executes the computer program, the object storage-based request processing method according to the first aspect and various possible designs of the first aspect is implemented.

[0019] The present disclosure provides a request processing method, apparatus, device, and storage medium based on object storage. The method includes: in response to a restart command from a user-mode daemon, loading a pre-stored object node file and an object name file from local storage into the user-mode daemon; wherein the object node file is used to maintain object node information, and the object name file is used to maintain object name information; based on the object node file, re-establishing a first mapping relationship between object node identifiers and object node information; and based on the object node file and the object name file, re-establishing a second mapping relationship between the directory node identifier of the parent directory where the object is located, object name information, and object node information; and processing object access requests sent by the kernel module through the restarted user-mode daemon based on the first and second mapping relationships. In the technical solution provided in this disclosure, by storing the object node file and object name file corresponding to the user-mode daemon process in local storage, information such as the object node file and object name file can be persistently saved. After the user-mode daemon process crashes and restarts, the object node file and object name file can be loaded from local storage and the mapping relationship can be re-established, realizing the consistency of information between the user-mode daemon process and the kernel module. This allows the object access request to continue to be processed without interruption, and there is no need to remount and restart the computing task. Therefore, computing resources and time are saved, and the user experience is improved. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of a request processing method based on object storage provided in related technologies;

[0022] Figure 2 A flowchart illustrating a request processing method based on object storage provided in this disclosure embodiment;

[0023] Figure 3 This is a schematic diagram illustrating a method for writing information to a local file, as provided in an embodiment of this disclosure.

[0024] Figure 4 This is a schematic diagram illustrating a method for storing object node information in an object node file, as provided in an embodiment of this disclosure.

[0025] Figure 5 A schematic diagram illustrating a request processing method based on object storage provided in an embodiment of this disclosure;

[0026] Figure 6 A schematic diagram illustrating a retry method for an object access request provided in an embodiment of this disclosure;

[0027] Figure 7 A schematic diagram of the structure of a request processing apparatus based on object storage provided in an embodiment of this disclosure;

[0028] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0030] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0031] First, the background technology and some terms involved in this application will be explained:

[0032] Object storage: Object storage is a technology for storing and managing data in an unstructured format (called objects).

[0033] FUSE: Filesystem in Userspace (FUSE) is a software interface for Unix-like computer operating systems that allows unprivileged users to create their own file systems without editing the kernel code.

[0034] FUSE Daemon: FUSE's user-space daemon, responsible for the implementation of the user-space file system.

[0035] inode: An inode (index node) is a data structure used in many Unix-like file systems to describe file system objects (including files, directories, device files, sockets, pipes, etc.).

[0036] Node Table: A mapping table used for the translation of access semantics between the file system and object storage. It stores information such as the inode number, name, and overall directory tree of the object file.

[0037] Object storage is a technology for storing and managing data in an unstructured format. Object storage cloud services are widely used across various industries due to their advantages: large scale, support for massive storage; elasticity and scalability; persistence, high reliability, and low cost.

[0038] In related technologies, objects in object storage cloud services can be accessed through FUSE (Filesystem in Userspace). The working principle of FUSE object storage export is as follows: object names are converted into files and directories, and the forward slash character (" / ") in the object name is interpreted as a directory separator. Thus, the FUSE system treats objects with the same prefix as files in the same directory. User programs can interact with the object storage cloud service based on the file system mounted by the FUSE client. The FUSE client can run on any device connected to the object storage cloud service (including cloud hosts or local hosts). Therefore, the FUSE export access method is well-suited for object storage, meeting the performance and scalability requirements of applications requiring file system semantics. Examples include data lakes, machine learning training, autonomous driving, gene analysis, and image rendering.

[0039] It's important to note that in the user-space file system, many operations require accessing objects via object node identifiers (e.g., inode numbers), while object storage cloud services require accessing objects via object paths. Therefore, to enable access to objects in the object storage cloud service through the user-space file system, a mapping table (e.g., a Node Table) needs to be created in the user-space file system for the semantic translation between the user-space file system and the object storage cloud service.

[0040] Kernel mode and user mode are two distinct operating states in an operating system, differing significantly in terms of permissions, functionality, and security. User mode has lower privileges and cannot directly access hardware devices (such as disks and network interfaces); it must request kernel services through system calls. Kernel mode has the highest privileges and can directly access hardware devices, managing core functions such as memory and process scheduling.

[0041] In the embodiments disclosed herein, such as Figure 1As shown, user programs and user-space daemons run in user space, ensuring system security and efficient operation. The virtual file system and the FUSE kernel module run in kernel space. The object storage cloud service is deployed on cloud servers to store objects (unstructured data). User programs can access objects stored in the object storage cloud service through the virtual file system and the FUSE kernel module running in kernel space.

[0042] For example, such as Figure 1 As shown, the object access process is as follows: The user program running in user mode sends an object access request to the virtual file system running in kernel mode. The virtual file system forwards the object access request to the FUSE kernel module running in kernel mode, which then sends the object access request to the user-mode daemon running in user mode. The user-mode daemon's high-level API implements a Node Table (mapping table) based on a memory data structure, responsible for the semantic conversion between inodes and file names. In the user-mode daemon, the low-level API first processes the access request and then passes it to the high-level API. In the high-level API, if the file is not recorded in the Node Table, the Node Table assigns it an inode number and returns it to the FUSE kernel module for subsequent access (at this point, the file information in the FUSE kernel module is consistent with the file information in the user-mode daemon). If the FUSE kernel module accesses the file via the inode number, the Node Table converts it to an object path. In the Object Storage SDK (Software Development Kit), the received access request parameter is the object path information, which is used to access the object storage cloud service.

[0043] However, the inventors discovered at least the following technical problems in the related technology: Under high load scenarios, the user-mode daemon is prone to crash. After the crash, the file information in the kernel is inconsistent with the file information of the user-mode daemon, which makes it impossible for object access requests to be automatically restored. At this time, it is necessary to remount and restart the computing task, thus wasting computing resources and time, resulting in a poor user experience.

[0044] Therefore, how to automatically recover object access requests, save computing resources and time to improve user experience is a technical problem that urgently needs to be solved.

[0045] To address the aforementioned technical problems, the inventors' technical concept is as follows: An independent Node Table supporting crash recovery is implemented, writing information related to Node Table creation to a local file at runtime. When the FUSE Daemon crashes, information can be recovered from the local file and the Node Table recreated, thereby ensuring information consistency between the FUSE Daemon and the kernel module, and preventing uninterrupted access requests.

[0046] Accordingly, the specific steps may include: First, in response to the restart command of the user-space daemon, loading the pre-stored object node file and object name file from local storage into the user-space daemon; wherein the object node file is used to maintain object node information, and the object name file is used to maintain object name information. Then, based on the object node file, re-establishing the first mapping relationship between object node identifiers and object node information, and re-establishing the second mapping relationship between the directory node identifier, object name information, and object node information of the parent directory where the object resides, based on the object node file and the object name file. Finally, through the restarted user-space daemon, based on the first and second mapping relationships, processing object access requests sent by the kernel module.

[0047] In this technical solution, by storing the object node file and object name file corresponding to the user-mode daemon process in local storage, information such as the object node file and object name file can be persistently saved. After the user-mode daemon process crashes and restarts, the object node file and object name file can be loaded from local storage and the mapping relationship can be re-established, achieving information consistency between the user-mode daemon process and the kernel module. This allows the processing of object access requests to continue without interruption, eliminating the need to remount and restart the computing task. Therefore, it saves computing resources and time and improves the user experience.

[0048] The following describes the specific implementation process of the object storage-based request processing method, apparatus, device, storage medium, and product involved in the embodiments of this disclosure. Some examples are merely illustrative and not intended to limit the scope. The execution subject of the object storage-based request processing method involved in the embodiments of this disclosure is an electronic device, which may be a terminal, server, etc.

[0049] Figure 2 A flowchart of a request processing method based on object storage provided in this disclosure embodiment is shown below. Figure 2 As shown, this object storage-based request processing method may include:

[0050] S201. In response to the restart command of the user-mode daemon, load the pre-stored object node file and object name file from local storage into the user-mode daemon; wherein the object node file is used to maintain object node information, and the object name file is used to maintain object name information.

[0051] In this embodiment, if the user-mode daemon abnormally shuts down, a restart command for the user-mode daemon will be generated. Data such as object node files and object name files in the user-mode daemon's memory are non-persistent and will be lost when the user-mode daemon abnormally shuts down. Data such as object node files and object name files in local storage are persistent and will not be lost when the user-mode daemon abnormally shuts down. In this case, pre-stored object node files and object name files can be loaded from local storage into the user-mode daemon's memory.

[0052] In some embodiments, when the user-mode daemon is running normally, crash recovery-related information is written to a local file. If the user-mode daemon abnormally shuts down, the relevant information can be loaded from the local file, allowing the user-mode daemon to continue processing object access requests after restarting. For example... Figure 3 As shown, when the user-space daemon is running normally, it can write crash recovery-related information such as object node files, object name files, transaction log files, and object descriptor files into the local storage of the Node Table through mmap (memory-mapped files).

[0053] In this embodiment of the disclosure, memory-mapped files allow the operating system to map a file on the hard disk into the virtual address space of a process. This allows programs to access file data as if it were ordinary memory, without needing to read or modify file content through traditional file I / O operations, thus improving the processing efficiency of object access requests.

[0054] Optionally, when the user-mode daemon is running normally, the method for writing crash recovery-related information to a local file may include the following steps (1) to (3):

[0055] (1) In response to receiving the first query request for any object, determine whether the object node information and object name information of the object have been stored in the object node file stored locally. If not, generate the object node information and object name information of the object, store the object node information in the object node file stored locally, and store the object name information in the object name file stored locally.

[0056] (2) In response to receiving the first read / write request of any object, obtain the request attribute information of the read / write request and the object path information of the object, generate the object descriptor information of the object based on the request attribute information and the object path information, and store the object descriptor information in the object descriptor file in local storage.

[0057] (3) In response to receiving an object access request from any object, generate log information corresponding to the object access request and store the log information in the transaction log file stored locally.

[0058] Optionally, the object node file includes multiple object node information entries for storing object metadata; wherein, the object metadata includes one or more of the following: object node identifier, version identifier, directory node identifier of the object's parent directory, object name identifier, and kernel reference count information. The object name file includes multiple object name information entries. The transaction log file includes log information corresponding to multiple object access requests. The object descriptor file includes multiple object descriptor information entries for storing object path information and request attribute information.

[0059] For example, such as Figure 3 As shown, the object node file includes object node information 1, object node information 2, ..., object node information M. The object name file includes object name information 1, object name information 2, ..., object name information N. The transaction log file includes log information 1, log information 2, ..., log information X. The object descriptor file includes object descriptor information 1, object descriptor information 2, ..., object descriptor information Y.

[0060] In some embodiments, each piece of information is stored in a structured manner in a corresponding local file. The common format of the persistent local files is an array-like arrangement of data structures. This allows the specific data structure to be located using an index.

[0061] For example, such as Figure 4 As shown, the information for each object node is stored in a structured manner in an object node file. The multiple object node information entries in this file are arranged in an array: index 0 for object node information 1, index 1 for object node information 2, and index 2 for object node information 3. Thus, a specific object node information can be found using its index.

[0062] S202. Based on the object node file, re-establish the first mapping relationship between the object node identifier and the object node information, and based on the object node file and the object name file, re-establish the second mapping relationship between the directory node identifier, object name information and object node information of the parent directory where the object is located.

[0063] In some embodiments, the object node file includes multiple object node information for storing object metadata, and the object metadata includes at least an object node identifier; accordingly, based on the object node file, a first mapping relationship between the object node identifier and the object node information is re-established, including: for each object node information in the object node file, obtaining the object node identifier in the object node information; and re-establishing the first mapping relationship between the object node identifier and the object node information.

[0064] Optionally, the object node information includes one or more of the following: object node identifier, version number corresponding to the object node identifier, directory node identifier of the parent directory, object name identifier, and kernel reference count. The object name identifier can be represented as a Name Buffer number or Name ID. The object node identifier can be represented as an inode number. The directory node identifier of the parent directory can be represented as the inode number of the parent directory.

[0065] For example, object node information can be represented as a Node structure, and the object node identifier can be represented as an inode number. In this case, the Node structure can be found using the inode number, and the initial mapping relationship between the inode number and the Node structure can be re-established.

[0066] In some embodiments, the object node file includes multiple object node information for storing object metadata, the object metadata including at least the directory node identifier of the parent directory where the object is located and the object name identifier; the object name file includes multiple object name information; accordingly, based on the object node file and the object name file, a second mapping relationship between the directory node identifier of the parent directory where the object is located, the object name information and the object node information is re-established, including: for each object node information in the object node file, obtaining the directory node identifier and the object name identifier of the parent directory where the object is located from the object node information; obtaining the object name information that matches the directory node identifier from the multiple object name information included in the object name file; and re-establishing the second mapping relationship between the directory node identifier of the parent directory where the object is located, the object name information and the object node information.

[0067] Optionally, the object name file includes object node identifiers and object name information. For example, the object name file can be represented as a Name Buffer structure.

[0068] For example, object node information can be represented as a Node structure, the directory node identifier of the parent directory where the object is located can be represented as the parent directory inode number, and the object name information is the object name. At this time, the Node structure can be found through the parent directory inode number and the object name, and a second mapping relationship between (parent directory inode number + object name) and the Node structure can be re-established.

[0069] In this embodiment of the disclosure, since the first mapping relationship and the second mapping relationship can be reconstructed based on the object node file and the object name file, it is not necessary to persist the first mapping relationship and the second mapping relationship in the local storage, thus saving the storage space of the local storage.

[0070] S203. The user-space daemon process after rebooting processes the object access requests sent by the kernel module based on the first and second mapping relationships.

[0071] In some embodiments, this step may include: obtaining the request type and request information of an object access request sent by a kernel module through a restarted user-mode daemon, wherein the object access request is initiated by a user program operating in user mode and forwarded to a kernel module operating in kernel mode via a virtual file system operating in kernel mode; determining a target mapping relationship that matches the request type from a first mapping relationship and a second mapping relationship; and processing the object access request according to the request information and the target mapping relationship.

[0072] Optionally, the request types for object access requests include: a first request type for obtaining object node information through object node identifiers and a second request type for obtaining object node information through directory node identifiers and object name information of the parent directory where the object is located.

[0073] Specifically, when the object access request is of type 1, the request information is the object node identifier. When the object access request is of type 2, the request information is the directory node identifier of the parent directory where the object is located and the object name information.

[0074] For example, the first request type includes request types such as GetAttr (retrievable object attribute request) and SetAttr (set object attribute request), in which case the request information for the object access request is the inode number. The second request type includes request types such as Lookup (lookup request) and Rename (rename request). In this case, the request information for the object access request is the parent directory inode number and the object name.

[0075] In some embodiments, processing an object access request based on request information and a target mapping relationship includes: invoking the target mapping relationship through an asynchronous request processing interface in a user-mode daemon; determining the storage path information corresponding to the object to be accessed based on the request information and the target mapping relationship; and accessing the object from the object storage database based on the storage path information.

[0076] Optionally, the request information for the object access request is the target object node identifier, and the target mapping relationship is a first mapping relationship between the object node identifier and the object node information. Accordingly, based on the request information and the target mapping relationship, the storage path information corresponding to the object to be accessed is determined, including:

[0077] (a1) Based on the target object node identifier, determine the first object node information corresponding to the target object node identifier from the first mapping relationship between the object node identifier and the object node information. The first object node information includes the directory node identifier and the object name identifier of the parent directory where the object to be accessed is located.

[0078] (a2) Based on the directory node identifier of the parent directory, determine the second object node information corresponding to the directory node identifier from the first mapping relationship between the object node identifier and the object node information, wherein the directory name identifier is in the second object node information; based on the object name identifier, obtain the object name information corresponding to the object name identifier from the object name file; and based on the directory name identifier, obtain the directory name information corresponding to the directory name identifier from the object name file; and based on the object name information and the directory name information, determine the object path information of the object to be accessed.

[0079] For example, the target object node is identified as inode11. Through inode11 and the first mapping relationship, the target object node information Node11 corresponding to inode11 is determined. This Node11 includes the directory node identifier inode10 of the parent directory where the object to be accessed is located and the object name identifier name11. At this time, through the directory node identifier inode10 and the first mapping relationship, the directory node information Node10 corresponding to inode10 is determined. This Node11 includes the directory name identifier name10.

[0080] The object name information corresponding to name11 is obtained from the object name file as "fileA", and the directory name information corresponding to name10 is "user1". Based on the object name information "fileA" and the directory name information "user1", the object path information of the object to be accessed is determined to be "user1 / fileA".

[0081] It should be noted that when determining the object path information, it is necessary to determine whether the parent directory of the current directory (e.g., user1) is the root directory. If so, the object path information is generated. If not, it is necessary to further determine the directory name of the parent directory of the current directory, until the parent directory of the current directory is the root directory. Here, the current directory is the most recently determined directory.

[0082] Optionally, the second object node information also includes the directory node identifier of the parent directory of the current directory. For example, inode5. In this case, based on the mapping relationship between inode5 and the first mapping, the directory node information Node5 corresponding to inode5 can be determined. This Node11 includes the directory name identifier name5, and the directory name information corresponding to name5 obtained from the object name file is "local". At this time, if the parent directory of the current directory "local" is the root directory, the object path information "local / user1 / fileA" is generated. Otherwise, it is necessary to further determine the directory name information of the parent directory of the current directory "local" until the parent directory of the current directory is the root directory.

[0083] Optionally, the request information for the object access request includes: the directory node identifier and object name information of the parent directory where the object is located, and the target mapping relationship is: a second mapping relationship between the directory node identifier, object name information, and object node information of the parent directory where the object is located. Accordingly, based on the request information and the target mapping relationship, the storage path information corresponding to the object to be accessed is determined, including:

[0084] (b1) Based on the directory node identifier and object name information of the parent directory where the object is located, determine the first object node information corresponding to the directory node identifier and object name information from the second mapping relationship between the directory node identifier, object name information and object node information of the parent directory where the object is located. The first object node information includes the object name identifier.

[0085] (b2) Based on the directory node identifier of the parent directory, determine the second object node information corresponding to the directory node identifier from the first mapping relationship between the object node identifier and the object node information, wherein the directory name identifier is in the second object node information; based on the object name identifier, obtain the object name information corresponding to the object name identifier from the object name file; and based on the directory name identifier, obtain the directory name information corresponding to the directory name identifier from the object name file; and based on the object name information and the directory name information, determine the object path information of the object to be accessed.

[0086] The method for determining object path information in (b2) is the same as the method for determining object path information in (a2) above, and will not be repeated here.

[0087] Optionally, such as Figure 5 As shown, the asynchronous request processing interface can be a low-level API interface in a user-space daemon process.

[0088] It should be noted that in existing technologies, object access requests are handled through high-level API interfaces in the user-space daemon. However, these high-level API interfaces are synchronous interfaces; that is, in the FUSE Daemon, a thread handling an object access request can only process the next object access request after the previous one has returned, thus failing to achieve asynchronous concurrency. In contrast, in this embodiment, the Node Table and object storage SDK are called through low-level API interfaces in the user-space daemon. This decoupled design allows for more flexible request processing, supports asynchronous concurrency of access requests, and therefore improves the efficiency of handling access requests.

[0089] This disclosure provides an object storage-based request processing method, which includes: in response to a restart command from a user-mode daemon, loading the object node file and object name file corresponding to the user-mode daemon from local storage; re-establishing a first mapping relationship between object node identifiers and object node information based on the object node file; and re-establishing a second mapping relationship between directory node identifiers, object name information, and object node information of the parent directory where the object resides based on the object node file and object name file; and processing object access requests sent by the kernel module based on the first and second mapping relationships. In the technical solution provided by this disclosure, by storing the object node file and object name file corresponding to the user-mode daemon in local storage, information such as the object node file and object name file can be persistently saved. After the user-mode daemon crashes and restarts, the object node file and object name file can be loaded from local storage, and the mapping relationship can be re-established, achieving information consistency between the user-mode daemon and the kernel module. This allows object access requests to continue being processed without interruption, eliminating the need to remount and restart the computing task, thus saving computing resources and time, and improving the user experience.

[0090] It's important to note that when the FUSE Daemon crashes, a request might be in an "in-flight" state, meaning it's in an intermediate processing state. If the request needs to modify multiple data items, at the time of the crash, some data might have been modified while others remained unchanged. Therefore, it's necessary to implement transactional atomicity for changes made to related data by a request. After crash recovery, in-flight requests will be retried. Before retrying, the Node Table is responsible for rolling back and restoring the data items involved in the request based on the transaction log.

[0091] In some embodiments, the process of retrying the execution of an object access request when the user-mode daemon abnormally shuts down, using transaction log files and object descriptor files stored locally, may include the following steps (1) to (3):

[0092] (1) Load the transaction log file and object descriptor file from local storage. The transaction log file includes log information corresponding to multiple object access requests, and the object descriptor file includes multiple object descriptor information used to store object path information and request attribute information.

[0093] (2) Obtain the target log information corresponding to the target object access request being processed when the user-mode daemon abnormally shuts down from the transaction log file.

[0094] (3) Based on the target log information, restore the object node file, object name file and object descriptor file, and reprocess the target object access request based on the restored object node file, object name file and object descriptor file.

[0095] In some embodiments, restoring the object node file, object name file, and object descriptor file based on the target log information includes: determining the target object node information corresponding to the target object from the object node file, determining the target object name information corresponding to the target object from the object name file, and obtaining the target object descriptor information corresponding to the target object access request from the object descriptor file; wherein, the target object is the object to be accessed corresponding to the target object access request; for each data item in the target object node information, target object name information, and target object descriptor information, obtaining the initial data information of the data item from the target log information, and modifying the current data information of the data item to the initial data information.

[0096] Optionally, determining the target object node information corresponding to the target object from the object node file, determining the target object name information corresponding to the target object from the object name file, and obtaining the target object descriptor information corresponding to the target object access request from the object descriptor file includes: determining the target object node information corresponding to the target object node identifier from multiple object node information included in the object node file based on the target object node identifier in the target log information; determining the target object name information corresponding to the target object node identifier from multiple object name information included in the object name file based on the target object node identifier in the target log information; and obtaining the target object descriptor information corresponding to the target object descriptor identifier from multiple object descriptor information included in the object descriptor file based on the target object descriptor identifier in the target log information.

[0097] For example, such as Figure 6As shown, the steps to restore the object node file, object name file, and object descriptor file based on the target log information include:

[0098] Step 1: Load all data structures and transaction logs from local files. Obtain the basic information structure using mmap, and then rebuild the mapping table. The data structures include object node files, object name files, and object descriptor files.

[0099] Step 2: Roll back the transaction log. The existence of a transaction log indicates that there were unfinished requests at the time of the crash, so it's uncertain whether the relevant data items have been modified, thus requiring a rollback. The relevant data items can be data items from object node information, object name information, or object descriptor information. For example, the version number corresponding to the object node identifier in the object node information.

[0100] Step 3: Delete the transaction log after rollback. After the relevant data items have been rolled back and restored, the transaction log can be deleted.

[0101] Step 4: Retry the in-flight requests that were not completed at the time of the crash. Requests that were not completed at the time of the crash are retried, and the entire request processing flow is repeated.

[0102] In this embodiment of the disclosure, since the atomicity of changes to the object node file, object name file and object descriptor file is achieved based on the locally stored transaction log file, the retry consistency of the in-flight request at the time of the crash and the information consistency with the kernel module are guaranteed. Therefore, it can be ensured that the user-mode daemon process after restarting can handle the target object access request that was not completed at the time of the crash.

[0103] Figure 7 This is a schematic diagram of the structure of a request processing apparatus based on object storage provided in an embodiment of this disclosure, as shown below. Figure 7 As shown, the request processing device includes:

[0104] The loading unit 701 is configured to load a pre-stored object node file and an object name file from local storage into the user-mode daemon process in response to a restart command from the user-mode daemon process; wherein the object node file is used to maintain object node information and the object name file is used to maintain object name information.

[0105] The mapping unit 702 is used to re-establish a first mapping relationship between object node identifier and object node information based on the object node file, and to re-establish a second mapping relationship between directory node identifier, object name information and object node information of the parent directory where the object is located based on the object node file and the object name file.

[0106] Processing unit 703 is used to process object access requests sent by the kernel module based on the first mapping relationship and the second mapping relationship through the restarted user-mode daemon process.

[0107] According to one or more embodiments of this disclosure, the processing unit 703 processes object access requests sent by the kernel module through a rebooted user-mode daemon process, based on the first mapping relationship and the second mapping relationship. This includes: obtaining the request type and request information of the object access request sent by the kernel module through the rebooted user-mode daemon process, wherein the object access request is initiated by a user program operating in user mode and forwarded to the kernel module operating in kernel mode via a virtual file system operating in kernel mode; determining a target mapping relationship matching the request type from the first mapping relationship and the second mapping relationship; and processing the object access request according to the request information and the target mapping relationship.

[0108] According to one or more embodiments of this disclosure, the processing unit 703 processes the object access request based on the request information and the target mapping relationship, including: calling the target mapping relationship through an asynchronous request processing interface in a user-mode daemon process; determining the storage path information corresponding to the object to be accessed based on the request information and the target mapping relationship; and accessing the object from the object storage database based on the storage path information.

[0109] According to one or more embodiments of this disclosure, the object node file includes a plurality of object node information for storing object metadata, the object metadata including at least an object node identifier; accordingly, the mapping unit 702 re-establishes a first mapping relationship between the object node identifier and the object node information based on the object node file, including: for each object node information in the object node file, obtaining the object node identifier in the object node information; and re-establishing the first mapping relationship between the object node identifier and the object node information.

[0110] According to one or more embodiments of this disclosure, the object node file includes multiple object node information for storing object metadata, the object metadata including at least a directory node identifier and an object name identifier of the parent directory where the object is located; the object name file includes multiple object name information; correspondingly, the mapping unit 702 re-establishes a second mapping relationship between the directory node identifier of the parent directory where the object is located, the object name information, and the object node information based on the object node file and the object name file, including: for each object node information in the object node file, obtaining the directory node identifier and the object name identifier of the parent directory where the object is located from the object node information; obtaining object name information that matches the directory node identifier from the multiple object name information included in the object name file; and re-establishing the second mapping relationship between the directory node identifier of the parent directory where the object is located, the object name information, and the object node information.

[0111] According to one or more embodiments of this disclosure, the processing apparatus further includes: a recovery request unit; the recovery request unit is configured to load a transaction log file and an object descriptor file from local storage, wherein the transaction log file includes log information corresponding to multiple object access requests, and the object descriptor file includes multiple object descriptor information for storing object path information and request attribute information; obtain target log information corresponding to the target object access request being processed when the user-mode daemon abnormally shuts down from the transaction log file; restore the object node file, the object name file, and the object descriptor file according to the target log information, and reprocess the target object access request according to the restored object node file, object name file, and object descriptor file.

[0112] According to one or more embodiments of this disclosure, the recovery request unit restores the object node file, the object name file, and the object descriptor file based on the target log information, including: determining target object node information corresponding to the target object from the object node file, determining target object name information corresponding to the target object from the object name file, and obtaining target object descriptor information corresponding to the target object access request from the object descriptor file; wherein, the target object is the object to be accessed corresponding to the target object access request; for each data item in the target object node information, the target object name information, and the target object descriptor information, obtaining the initial data information of the data item from the target log information, and modifying the current data information of the data item to the initial data information.

[0113] According to one or more embodiments of this disclosure, the recovery request unit determines target object node information corresponding to the target object from the object node file, determines target object name information corresponding to the target object from the object name file, and obtains target object descriptor information corresponding to the target object access request from the object descriptor file, including: determining target object node information corresponding to the target object node identifier from a plurality of object node information included in the object node file based on the target object node identifier in the target log information; determining target object name information corresponding to the target object node identifier from a plurality of object name information included in the object name file based on the target object node identifier in the target log information; and obtaining target object descriptor information corresponding to the target object descriptor identifier from a plurality of object descriptor information included in the object descriptor file based on the target object descriptor identifier in the target log information.

[0114] According to one or more embodiments of this disclosure, the processing apparatus further includes: a storage unit; the storage unit is configured to, in response to receiving a first query request from any object, determine whether object node information and object name information of the object are already stored in a locally stored object node file; if not, generate object node information and object name information of the object, store the object node information in a locally stored object node file, and store the object name information in a locally stored object name file; and / or, in response to receiving a first read / write request from any object, obtain request attribute information of the read / write request and object path information of the object, generate object descriptor information of the object based on the request attribute information and the object path information, and store the object descriptor information in a locally stored object descriptor file; and / or, in response to receiving an object access request from any object, generate log information corresponding to the object access request, and store the log information in a locally stored transaction log file.

[0115] This disclosure provides an object storage-based request processing device. By storing the object node file and object name file corresponding to the user-mode daemon process in local storage, the information such as the object node file and object name file can be persistently saved. After the user-mode daemon process crashes and restarts, the object node file and object name file can be loaded from local storage and the mapping relationship can be re-established. This ensures information consistency between the user-mode daemon process and the kernel module, allowing object access requests to continue to be processed without interruption. Consequently, there is no need to remount and restart the computing task, saving computing resources and time and improving the user experience.

[0116] Figure 8This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure, with reference to... Figure 8 The electronic device 800 can be a terminal device or a server. The terminal device can include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, personal digital assistants (PDAs), tablet computers, portable media players (PMPs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0117] like Figure 8 As shown, the electronic device 800 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage device 808 into a random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the electronic device 800. The processing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0118] Typically, the following devices can be connected to I / O interface 805: input devices 806 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 807 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 808 including, for example, magnetic tapes, hard disks, etc.; and communication devices 809. Communication device 809 allows electronic device 800 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 8 An electronic device 800 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0119] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 809, or installed from a storage device 808, or installed from a ROM 802. When the computer program is executed by a processing device 801, it performs the functions defined in the methods of embodiments of this disclosure.

[0120] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0121] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0122] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods shown in the above embodiments.

[0123] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0124] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0125] The units described in the embodiments of this disclosure can be implemented in software or in hardware. The name of a unit does not necessarily limit the unit itself; for example, the first acquisition unit can also be described as "a unit that acquires at least two Internet Protocol addresses".

[0126] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0127] The object storage-based request processing method, apparatus, electronic device, storage medium, and program product provided in this disclosure persists information such as the object node file and object name file corresponding to the user-mode daemon process by storing them in local storage. After the user-mode daemon process crashes and restarts, the object node file and object name file can be loaded from local storage and the mapping relationship re-established, ensuring information consistency between the user-mode daemon process and the kernel module. This allows object access requests to continue being processed without interruption, eliminating the need to remount and restart the computing task. Therefore, it saves computing resources and time, and improves the user experience.

[0128] In a first aspect, according to one or more embodiments of this disclosure, a request processing method based on object storage is provided, comprising:

[0129] In response to a restart command from the user-mode daemon, a pre-stored object node file and object name file are loaded from local storage into the user-mode daemon; wherein the object node file is used to maintain object node information, and the object name file is used to maintain object name information.

[0130] Based on the object node file, a first mapping relationship between object node identifier and object node information is re-established; and based on the object node file and the object name file, a second mapping relationship between directory node identifier, object name information and object node information of the parent directory where the object is located is re-established.

[0131] The restarted user-space daemon processes object access requests sent by the kernel module based on the first and second mapping relationships.

[0132] According to one or more embodiments of this disclosure, the step of processing object access requests sent by kernel modules through a rebooted user-mode daemon based on the first mapping relationship and the second mapping relationship includes: obtaining the request type and request information of the object access request sent by the kernel module through the rebooted user-mode daemon, wherein the object access request is initiated by a user program running in user mode and forwarded to the kernel module running in kernel mode via a virtual file system running in kernel mode; determining a target mapping relationship matching the request type from the first mapping relationship and the second mapping relationship; and processing the object access request according to the request information and the target mapping relationship.

[0133] According to one or more embodiments of this disclosure, processing the object access request based on the request information and the target mapping relationship includes: invoking the target mapping relationship through an asynchronous request processing interface in a user-mode daemon; determining the storage path information corresponding to the object to be accessed based on the request information and the target mapping relationship; and accessing the object from the object storage database based on the storage path information.

[0134] According to one or more embodiments of this disclosure, the object node file includes a plurality of object node information for storing object metadata, the object metadata including at least an object node identifier; accordingly, the step of re-establishing the first mapping relationship between the object node identifier and the object node information according to the object node file includes: for each object node information in the object node file, obtaining the object node identifier in the object node information; and re-establishing the first mapping relationship between the object node identifier and the object node information.

[0135] According to one or more embodiments of this disclosure, the object node file includes multiple object node information for storing object metadata, the object metadata including at least a directory node identifier and an object name identifier of the parent directory where the object is located; the object name file includes multiple object name information; correspondingly, the step of re-establishing the second mapping relationship between the directory node identifier, object name information and object node information of the parent directory where the object is located based on the object node file and the object name file includes: for each object node information in the object node file, obtaining the directory node identifier and object name identifier of the parent directory where the object is located from the object node information; obtaining object name information that matches the directory node identifier from the multiple object name information included in the object name file; and re-establishing the second mapping relationship between the directory node identifier, object name information and object node information of the parent directory where the object is located.

[0136] According to one or more embodiments of this disclosure, the method further includes: loading a transaction log file and an object descriptor file from local storage, wherein the transaction log file includes log information corresponding to multiple object access requests, and the object descriptor file includes multiple object descriptor information for storing object path information and request attribute information; obtaining target log information corresponding to the target object access request being processed when the user-mode daemon abnormally shut down from the transaction log file; restoring the object node file, the object name file, and the object descriptor file according to the target log information; and reprocessing the target object access request according to the restored object node file, object name file, and object descriptor file.

[0137] According to one or more embodiments of this disclosure, restoring the object node file, the object name file, and the object descriptor file based on the target log information includes: determining target object node information corresponding to the target object from the object node file, determining target object name information corresponding to the target object from the object name file, and obtaining target object descriptor information corresponding to the target object access request from the object descriptor file; wherein, the target object is the object to be accessed corresponding to the target object access request; for each data item in the target object node information, the target object name information, and the target object descriptor information, obtaining the initial data information of the data item from the target log information, and modifying the current data information of the data item to the initial data information.

[0138] According to one or more embodiments of this disclosure, determining the target object node information corresponding to the target object from the object node file, determining the target object name information corresponding to the target object from the object name file, and obtaining the target object descriptor information corresponding to the target object access request from the object descriptor file includes: determining the target object node information corresponding to the target object node identifier from a plurality of object node information included in the object node file based on the target object node identifier in the target log information; determining the target object name information corresponding to the target object node identifier from a plurality of object name information included in the object name file based on the target object node identifier in the target log information; and obtaining the target object descriptor information corresponding to the target object descriptor identifier from a plurality of object descriptor information included in the object descriptor file based on the target object descriptor identifier in the target log information.

[0139] According to one or more embodiments of this disclosure, the method further includes: in response to receiving a first query request from any object, determining whether object node information and object name information of the object are already stored in a locally stored object node file; if not, generating object node information and object name information of the object, storing the object node information in a locally stored object node file, and storing the object name information in a locally stored object name file; and / or, in response to receiving a first read / write request from any object, obtaining request attribute information of the read / write request and object path information of the object, generating object descriptor information of the object based on the request attribute information and the object path information, and storing the object descriptor information in a locally stored object descriptor file; and / or, in response to receiving an object access request from any object, generating log information corresponding to the object access request, and storing the log information in a locally stored transaction log file.

[0140] Secondly, according to one or more embodiments of this disclosure, an object storage-based request processing apparatus is provided, comprising:

[0141] A loading unit is configured to load a pre-stored object node file and an object name file from local storage into the user-mode daemon process in response to a restart command from the user-mode daemon process; wherein the object node file is used to maintain object node information, and the object name file is used to maintain object name information;

[0142] The mapping unit is used to re-establish a first mapping relationship between object node identifier and object node information based on the object node file, and to re-establish a second mapping relationship between directory node identifier, object name information and object node information of the parent directory where the object is located based on the object node file and the object name file.

[0143] The processing unit is used to process object access requests sent by the kernel module based on the first mapping relationship and the second mapping relationship through the restarted user-mode daemon process.

[0144] According to one or more embodiments of this disclosure, the processing unit processes object access requests sent by the kernel module through a restarted user-mode daemon process, based on the first mapping relationship and the second mapping relationship. This includes: obtaining the request type and request information of the object access request sent by the kernel module through the restarted user-mode daemon process, wherein the object access request is initiated by a user program operating in user mode and forwarded to the kernel module operating in kernel mode via a virtual file system operating in kernel mode; determining a target mapping relationship matching the request type from the first mapping relationship and the second mapping relationship; and processing the object access request according to the request information and the target mapping relationship.

[0145] According to one or more embodiments of this disclosure, the processing unit processes the object access request based on the request information and the target mapping relationship, including: invoking the target mapping relationship through an asynchronous request processing interface in a user-mode daemon process; determining the storage path information corresponding to the object to be accessed based on the request information and the target mapping relationship; and accessing the object from the object storage database based on the storage path information.

[0146] According to one or more embodiments of this disclosure, the object node file includes a plurality of object node information for storing object metadata, the object metadata including at least an object node identifier; accordingly, the mapping unit re-establishes a first mapping relationship between the object node identifier and the object node information based on the object node file, including: for each object node information in the object node file, obtaining the object node identifier in the object node information; and re-establishing the first mapping relationship between the object node identifier and the object node information.

[0147] According to one or more embodiments of this disclosure, the object node file includes multiple object node information for storing object metadata, the object metadata including at least a directory node identifier and an object name identifier of the parent directory where the object is located; the object name file includes multiple object name information; correspondingly, the mapping unit re-establishes a second mapping relationship between the directory node identifier of the parent directory where the object is located, the object name information, and the object node information based on the object node file and the object name file, including: for each object node information in the object node file, obtaining the directory node identifier and the object name identifier of the parent directory where the object is located from the object node information; obtaining object name information that matches the directory node identifier from the multiple object name information included in the object name file; and re-establishing the second mapping relationship between the directory node identifier of the parent directory where the object is located, the object name information, and the object node information.

[0148] According to one or more embodiments of this disclosure, the processing apparatus further includes: a recovery request unit; the recovery request unit is configured to load a transaction log file and an object descriptor file from local storage, wherein the transaction log file includes log information corresponding to multiple object access requests, and the object descriptor file includes multiple object descriptor information for storing object path information and request attribute information; obtain target log information corresponding to the target object access request being processed when the user-mode daemon abnormally shuts down from the transaction log file; restore the object node file, the object name file, and the object descriptor file according to the target log information, and reprocess the target object access request according to the restored object node file, object name file, and object descriptor file.

[0149] According to one or more embodiments of this disclosure, the recovery request unit restores the object node file, the object name file, and the object descriptor file based on the target log information, including: determining target object node information corresponding to the target object from the object node file, determining target object name information corresponding to the target object from the object name file, and obtaining target object descriptor information corresponding to the target object access request from the object descriptor file; wherein, the target object is the object to be accessed corresponding to the target object access request; for each data item in the target object node information, the target object name information, and the target object descriptor information, obtaining the initial data information of the data item from the target log information, and modifying the current data information of the data item to the initial data information.

[0150] According to one or more embodiments of this disclosure, the recovery request unit determines target object node information corresponding to the target object from the object node file, determines target object name information corresponding to the target object from the object name file, and obtains target object descriptor information corresponding to the target object access request from the object descriptor file, including: determining target object node information corresponding to the target object node identifier from a plurality of object node information included in the object node file based on the target object node identifier in the target log information; determining target object name information corresponding to the target object node identifier from a plurality of object name information included in the object name file based on the target object node identifier in the target log information; and obtaining target object descriptor information corresponding to the target object descriptor identifier from a plurality of object descriptor information included in the object descriptor file based on the target object descriptor identifier in the target log information.

[0151] According to one or more embodiments of this disclosure, the processing apparatus further includes: a storage unit; the storage unit is configured to, in response to receiving a first query request from any object, determine whether object node information and object name information of the object are already stored in a locally stored object node file; if not, generate object node information and object name information of the object, store the object node information in a locally stored object node file, and store the object name information in a locally stored object name file; and / or, in response to receiving a first read / write request from any object, obtain request attribute information of the read / write request and object path information of the object, generate object descriptor information of the object based on the request attribute information and the object path information, and store the object descriptor information in a locally stored object descriptor file; and / or, in response to receiving an object access request from any object, generate log information corresponding to the object access request, and store the log information in a locally stored transaction log file.

[0152] Thirdly, according to one or more embodiments of the present disclosure, an electronic device is provided, comprising: at least one processor and a memory;

[0153] The memory stores computer-executed instructions;

[0154] The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the object storage-based request processing method as described in the first aspect and various possible designs of the first aspect.

[0155] Fourthly, according to one or more embodiments of the present disclosure, a computer-readable storage medium is provided, wherein computer-executable instructions are stored therein, and when a processor executes the computer-executable instructions, the object storage-based request processing method described in the first aspect and various possible designs of the first aspect is implemented.

[0156] Fifthly, according to one or more embodiments of the present disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the object storage-based request processing method as described in the first aspect and various possible designs of the first aspect.

[0157] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0158] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0159] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A request processing method based on object storage, characterized in that, The method includes: In response to a restart command from the user-mode daemon, a pre-stored object node file and object name file are loaded from local storage into the user-mode daemon; wherein the object node file is used to maintain object node information, and the object name file is used to maintain object name information. Based on the object node file, a first mapping relationship between object node identifier and object node information is re-established; and based on the object node file and the object name file, a second mapping relationship between directory node identifier, object name information and object node information of the parent directory where the object is located is re-established. The restarted user-space daemon processes object access requests sent by the kernel module based on the first and second mapping relationships.

2. The request processing method according to claim 1, characterized in that, The process of handling object access requests sent by the kernel module through the restarted user-space daemon, based on the first and second mapping relationships, includes: The request type and request information of the object access request sent by the kernel module are obtained through the restarted user-mode daemon process. The object access request is initiated by a user program running in user mode and forwarded to the kernel module running in kernel mode via the virtual file system running in kernel mode. From the first mapping relationship and the second mapping relationship, determine the target mapping relationship that matches the request type; The object access request is processed based on the request information and the target mapping relationship.

3. The request processing method according to claim 2, characterized in that, The step of processing the object access request based on the request information and the target mapping relationship includes: The target mapping relationship is invoked through the asynchronous request processing interface in the user-mode daemon process; Based on the request information and the target mapping relationship, determine the storage path information corresponding to the object to be accessed; Based on the storage path information, the object is accessed from the object storage database.

4. The request processing method according to claim 1, characterized in that, The object node file includes multiple object node information for storing object metadata, and the object metadata includes at least an object node identifier; Accordingly, the step of re-establishing the first mapping relationship between object node identifiers and object node information based on the object node file includes: For each object node information in the object node file, obtain the object node identifier in the object node information; Re-establish the first mapping relationship between the object node identifier and the object node information.

5. The request processing method according to claim 1, characterized in that, The object node file includes multiple object node information for storing object metadata, and the object metadata includes at least the directory node identifier of the parent directory where the object is located and the object name identifier; the object name file includes multiple object name information. Accordingly, the step of re-establishing the second mapping relationship between the directory node identifier of the parent directory where the object is located, the object name information, and the object node information based on the object node file and the object name file includes: For each object node information in the object node file, obtain the directory node identifier and object name identifier of the parent directory where the object is located in the object node information; Obtain the object name information that matches the directory node identifier from the multiple object name information included in the object name file; Re-establish the second mapping relationship between the directory node identifier of the parent directory where the object is located, the object name information, and the object node information.

6. The request processing method according to claim 1, characterized in that, The method further includes: Load transaction log files and object descriptor files from local storage, wherein the transaction log files include log information corresponding to multiple object access requests, and the object descriptor files include multiple object descriptor information for storing object path information and request attribute information; Obtain the target log information corresponding to the target object access request that was being processed when the user-mode daemon abnormally shut down from the transaction log file; Based on the target log information, restore the object node file, the object name file, and the object descriptor file, and reprocess the target object access request based on the restored object node file, object name file, and object descriptor file.

7. The request processing method according to claim 6, characterized in that, The step of restoring the object node file, the object name file, and the object descriptor file based on the target log information includes: The target object node information corresponding to the target object is determined from the object node file, the target object name information corresponding to the target object is determined from the object name file, and the target object descriptor information corresponding to the target object access request is obtained from the object descriptor file; wherein, the target object is the object to be accessed corresponding to the target object access request; For each data item in the target object node information, the target object name information, and the target object descriptor information, the initial data information of the data item is obtained from the target log information, and the current data information of the data item is modified to the initial data information.

8. The request processing method according to claim 7, characterized in that, The steps of determining the target object node information corresponding to the target object from the object node file, determining the target object name information corresponding to the target object from the object name file, and obtaining the target object descriptor information corresponding to the target object access request from the object descriptor file include: Based on the target object node identifier in the target log information, determine the target object node information corresponding to the target object node identifier from the multiple object node information included in the object node file; Based on the target object node identifier in the target log information, determine the target object name information corresponding to the target object node identifier from the multiple object name information included in the object name file; Based on the target object descriptor identifier in the target log information, obtain the target object descriptor information corresponding to the target object descriptor identifier from the multiple object descriptor information included in the object descriptor file.

9. The request processing method according to any one of claims 1 to 8, characterized in that, The method further includes: In response to receiving the first query request for any object, determine whether the object node information and object name information of the object are already stored in the locally stored object node file. If not, generate the object node information and object name information of the object, store the object node information in the locally stored object node file, and store the object name information in the locally stored object name file; and / or, In response to receiving the first read / write request for any object, the system obtains the request attribute information of the read / write request and the object path information of the object; generates object descriptor information for the object based on the request attribute information and the object path information; and stores the object descriptor information in a locally stored object descriptor file; and / or, In response to receiving an object access request from any object, log information corresponding to the object access request is generated, and the log information is stored in a locally stored transaction log file.

10. A request processing apparatus based on object storage, characterized in that, The device includes: A loading unit is configured to load a pre-stored object node file and an object name file from local storage into the user-mode daemon process in response to a restart command from the user-mode daemon process; wherein the object node file is used to maintain object node information, and the object name file is used to maintain object name information; The mapping unit is used to re-establish a first mapping relationship between object node identifier and object node information based on the object node file, and to re-establish a second mapping relationship between directory node identifier, object name information and object node information of the parent directory where the object is located based on the object node file and the object name file. The processing unit is used to process object access requests sent by the kernel module based on the first mapping relationship and the second mapping relationship through the restarted user-mode daemon process.

11. An electronic device, characterized in that, include: Processor and memory; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the object storage-based request processing method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, implement the object-store-based request processing method as described in any one of claims 1 to 9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the object storage-based request processing method as described in any one of claims 1 to 9.

Images