File system metadata management method and apparatus, electronic device, and storage medium

Abstract

The present application provides a file system metadata management method and apparatus, an electronic device, and a storage medium. The method is executed by a computing device. The computing device has communication connections with at least two memories. The at least two memories store a metadata relationship table and a metadata entity table, the metadata entity table stores metadata of objects in a file system, the objects are files or directories, and the metadata relationship table stores parent-child relationships between the objects in the file system. The method comprises: acquiring a path parsing request, wherein the path parsing request comprises path information of a target object; in response to the path parsing request, acquiring an identifier of the target object from a parent-child relationship corresponding to the path information in a metadata relationship table; and acquiring metadata corresponding to the identifier of the target object from a metadata entity table.

Description

File system metadata management methods, devices, electronic devices and storage media

[0001] This application claims priority to Chinese Patent Application No. 202410968748.4, filed on July 18, 2024, entitled "Method, Apparatus, Electronic Device and Readable Medium for File System Metadata Management", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer technology, and in particular to a file system metadata management method, apparatus, electronic device, and storage medium.

[0003] Background of the Invention

[0004] With the development of internet technology, the amount of data carried by big data platforms has increased dramatically. In cloud-based distributed file systems, the file system metadata typically uses a directory tree storage structure and is stored in system memory or on the local disk using a key-value storage engine. As the amount of file system metadata increases, the demands on the file system's memory or local disk space and performance also increase, posing challenges to the file system's capacity and operating efficiency. Summary of the Invention

[0005] In view of the above-mentioned technical problems, this application provides a file system metadata management method, apparatus, electronic device and storage medium to improve the data carrying capacity and operating efficiency of the file system.

[0006] This application provides a file system metadata management method executed by a computing device having communication connections with at least two storage devices. The at least two storage devices store a metadata relationship table and a metadata entity table. The metadata entity table stores metadata for each object in the file system, where an object is a file or directory. The metadata relationship table stores parent-child relationships between objects in the file system.

[0007] The method includes:

[0008] Obtain a path resolution request, wherein the path resolution request includes path information of the target object;

[0009] In response to the path resolution request, the identifier of the target object is obtained from the parent-child relationship corresponding to the path information in the metadata relationship table;

[0010] Obtain the metadata corresponding to the identifier of the target object from the metadata entity table.

[0011] This application also provides a file system metadata management device. The device has a communicative connection to at least two storage devices, which store a metadata relationship table and a metadata entity table. The metadata entity table stores metadata for each object in the file system, where objects are files or directories. The metadata relationship table stores parent-child relationships between objects in the file system. The device includes:

[0012] The request acquisition module is configured to acquire path resolution requests, which include path information of the target object.

[0013] The object acquisition module is configured to, in response to the path resolution request, obtain the identifier of the target object from the parent-child relationship corresponding to the path information in the metadata relationship table;

[0014] The information reading module is configured to retrieve the metadata corresponding to the identifier of the target object from the metadata entity table.

[0015] This application also provides an electronic device, which includes: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the above instructions to implement the methods of the various embodiments.

[0016] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the processor to implement the methods of the various embodiments.

[0017] This application also provides a computer program product or computer program, including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads and executes the computer instructions from the computer-readable storage medium to implement the methods of the various embodiments.

[0018] In this embodiment, the metadata of directories and files in the file system is stored and managed using metadata entity tables and metadata relationship tables. The metadata entity tables and metadata relationship tables can be stored in different physical storage devices, so that the growth of the file system metadata is no longer affected and constrained by the single-machine storage mechanism, thereby improving the data carrying capacity and operating efficiency of the file system.

[0019] Brief description of the attached figures

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0021] Figure 1 shows the system architecture of the file system metadata management method of this application applied to a cloud host platform.

[0022] Figure 2A is an overview flowchart of the file system metadata management method according to an embodiment of this application.

[0023] Figure 2B is a schematic diagram of the directory tree of file system metadata in an embodiment of this application.

[0024] Figure 3 is a flowchart of a file system metadata management method according to an embodiment of this application.

[0025] Figure 4 is a flowchart of a file system metadata management method according to an embodiment of this application.

[0026] Figure 5 is a schematic diagram of the metadata entity table and entity partition table in the embodiments of this application.

[0027] Figure 6 is a flowchart of a file system metadata management method according to an embodiment of this application.

[0028] Figure 7 is a schematic diagram of the metadata relationship table and the relationship partition table in the embodiments of this application.

[0029] Figure 8 is a flowchart of a file system metadata management method according to an embodiment of this application.

[0030] Figure 9 is a schematic diagram of the relational partitioning table expansion scheme in the embodiments of this application.

[0031] Figure 10 shows an example block diagram of a file system metadata management device in an embodiment of this application.

[0032] Figure 11 shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiments of this application.

[0033] Methods of implementing the present invention

[0034] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0035] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0036] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve the predetermined function, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functions of that module or unit.

[0037] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0038] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0039] The solution proposed in this application can be applied to distributed file systems for big data, and specifically in file system metadata management scenarios based on cloud platforms.

[0040] Metadata is data used to describe data, such as supporting functions that indicate storage location, resource attributes, and file records. File system metadata is typically a collection of file attributes, the directory hierarchy it resides in, and data indexes.

[0041] In this application, file system metadata can be managed through metadata services on a cloud platform, and at the same time, data storage services on the cloud platform are also used to store the actual storage objects of the file system.

[0042] The solution proposed in this application is primarily applied to big data scenarios. Big data refers to data sets that cannot be captured, managed, and processed within a certain timeframe using conventional software tools. It represents massive, rapidly growing, and diverse information assets that require new processing models to achieve stronger decision-making, insight discovery, and process optimization capabilities. With the advent of the cloud era, big data has attracted increasing attention. Big data requires specialized technologies to effectively process large amounts of data within a tolerable timeframe. Technologies suitable for big data include massively parallel processing databases, data mining, distributed file systems, distributed databases, cloud computing platforms, the Internet, and scalable storage systems.

[0043] With the development of internet technology, the amount of data carried by big data platforms has increased dramatically. Massive file storage is a problem that distributed file systems based on cloud technology need to solve, and the storage of file metadata is crucial to the operation of these systems. In related technologies, file system metadata can be stored in system memory using a directory tree structure or on local disk using a key-value storage engine. However, with these technologies, as the amount of file system metadata increases, the pressure on the file system's memory or local disk space and performance also increases. This limits the file system's performance and storage capacity to the available memory or local disk space. Furthermore, excessive memory or disk space consumption by file system metadata can negatively impact the file system's capacity and operating efficiency.

[0044] Based on this, the technical solution of this application proposes a file system metadata management scheme. Referring to Figure 1, the system structure of the file system metadata management method applied to the metadata management system in this application embodiment can mainly include two parts: a file system 110 and a metadata database 120. Devices in each part of the system structure can include smartphones, tablets, laptops, smart voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc. These devices can also be servers providing various services; they can be independent physical servers, server clusters composed of multiple physical servers, or distributed systems. They can also be cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Various types of communication media can exist between devices, such as wired or wireless communication links.

[0045] Depending on the implementation requirements, the system architecture in this application embodiment can have any number of terminal devices and servers. For example, the devices such as the file system 110 and the metadata database 120 can be a server group composed of multiple server devices. In addition, the technical solutions provided in this application embodiment can be applied to a computing platform, or can be implemented jointly by various parts of the system, and this application does not impose any special limitations on this.

[0046] As shown in Figure 1, the user terminal accesses the file system 110 to manage and access specific files. The file system 110 then sends various metadata management instructions to the metadata database 120 according to user commands or system rules, including operations such as creating, deleting, updating, and querying objects in the file system.

[0047] Figure 2A shows an overview flowchart of a file system metadata management method according to an embodiment of this application. This method can be executed by a computing device with computing processing capabilities, such as a server or terminal device of a distributed file system or metadata management device. The computing device has communication connections with at least two storage devices. These at least two storage devices store a metadata relationship table and a metadata entity table. The metadata entity table stores metadata for each object in the file system; the object can be a file or a directory. The metadata relationship table stores the parent-child relationships between objects in the file system. As shown in Figure 2A, the method includes the following steps.

[0048] In step S210, a path resolution request is obtained. This path resolution request includes the path information of the target object.

[0049] In S220, in response to the path resolution request, the identifier of the target object is obtained from the parent-child relationship corresponding to the path information in the metadata relationship table.

[0050] In S230, the metadata corresponding to the identifier of the target object is obtained from the metadata entity table.

[0051] According to the methods of various embodiments, the metadata of directories and files in the file system is no longer stored and managed using a directory tree approach, but is instead stored and maintained using metadata entity tables and metadata relationship tables. The metadata entity tables and metadata relationship tables can be stored in different physical storage devices, so that the growth of the file system metadata is no longer affected or constrained by the single-machine storage mechanism, thereby improving the data carrying capacity and operating efficiency of the file system.

[0052] In the various embodiments including this application specification and claims (hereinafter referred to as all embodiments of this application), the metadata entity table can also be implemented by multiple logically independent tables to achieve distributed storage and management of metadata. In this case, the metadata entity table can be composed of at least two entity partition tables stored in the at least two storage devices. Each of the at least two entity partition tables corresponds to at least one object in the file system and stores the metadata of the corresponding object. In this case, the step of obtaining the metadata corresponding to the identifier of the target object from the metadata entity table in all embodiments can include: determining the target entity partition table corresponding to the identifier of the target object; and obtaining the metadata corresponding to the identifier of the target object from the target entity partition table.

[0053] In this way, the metadata entity table is implemented as at least two entity partition tables, logically isolated from each other. That is, operations on one entity partition table can be completed only within that partition table, without affecting other entity partition tables. Thus, these entity partition tables can be stored and processed independently, for example, distributed across at least two storage devices (e.g., on at least two physical servers). This further reduces the data volume of a single table, facilitating the distributed storage and management of massive amounts of metadata.

[0054] In all embodiments of this application, each entity partition table can be associated with at least one object (i.e., a directory or file) to store the metadata of the corresponding object (used to describe various attribute values ​​of the object, and therefore also called entity attribute information of the metadata entity, where the metadata entity refers to the metadata of an object).

[0055] For example, the identifiers of at least one object corresponding to each entity partition table can be within the same value range. For instance, the value range of the object identifiers corresponding to the first entity partition table is 0000 to 0050; the value range of the object identifiers corresponding to the second entity partition table is 0051 to 0100, and so on. In all embodiments, when determining the target entity partition table corresponding to the identifier of an object, the entity partition table corresponding to the value range to which the object identifier belongs can be used as the target entity partition table.

[0056] For example, the identifiers of at least one object correspond to the same encoded value. This encoded value is obtained by a preset algorithm (e.g., a hash algorithm). In all embodiments, when determining the target entity partition table corresponding to the identifier of an object, the preset algorithm can be used to determine the encoded value corresponding to the identifier of the object; the entity partition table corresponding to the encoded value is then determined as the target entity partition table.

[0057] The above are only examples of possible implementation methods; other examples will not be listed one by one.

[0058] By distributing the metadata of each object to different entity partition tables based on the object's identifier, the efficiency of metadata maintenance and management can be improved.

[0059] In all embodiments of this application, the metadata relationship table can also be implemented by multiple logically independent tables to achieve distributed storage and management of metadata. In this case, the metadata relationship table can consist of at least two relationship partition tables stored in at least two storage devices. Each of the at least two relationship partition tables corresponds to at least one directory in the file system and stores the parent-child relationship between the corresponding directory and the objects within that directory. In this case, the step of obtaining the identifier of an object from the metadata relationship table in all embodiments can include: obtaining the identifier of the object from the target relationship partition table corresponding to the parent directory of the object in the at least two relationship partition tables.

[0060] The metadata relational table is implemented as at least two relational partition tables, which together constitute the metadata relational table. Each relational partition table is logically isolated from the others; that is, operations on one relational partition table can be completed only within that table, without affecting other partition tables. In this way, these relational partition tables can be stored and processed independently, for example, distributed across at least two storage devices (e.g., on at least two physical servers). This further reduces the data volume of a single table, facilitating the distributed storage and management of massive amounts of metadata.

[0061] In all embodiments of this application, when the metadata relationship table is implemented by at least two relationship partition tables, each parent-child relationship in each relationship partition table may include the identifier of a directory and the name and identifier of an object in the directory. For example, each parent-child relationship may be stored as an entry in the relationship partition table, and the elements in the entry include the directory identifier of the parent directory in the parent-child relationship, and the identifier and name of the object that is the child in the parent-child relationship. In this case, the step of obtaining the identifier of an object from at least two relationship partition tables in all embodiments may include: determining the identifier of the parent directory of the object in at least two relationship partition tables based on the identifier of the root directory of a preset file system and the name of at least one directory in the path information of the object; determining the target relationship partition table corresponding to the identifier of the parent directory in at least two relationship partition tables; and obtaining the identifier of the object from the parent-child relationships in the target relationship partition table that include the identifier of the parent directory and the name of the object.

[0062] For example, when the path information of the target object is in the format of root directory / (possibly first-level directory / second-level directory.... / parent directory / ), the identifier of the first object can be obtained from the relational partition table corresponding to the root directory based on the preset root directory identifier and the name of the object at the first level under the root directory in the path information (referred to as the first object). That is, the identifier of the first object in the parent-child relationship corresponding to the root directory identifier and the name of the first object in the relational partition table can be obtained.

[0063] If the first object is the target object, then the identifier of the target object is determined to be the identifier of the first object.

[0064] If the first object is not the target object, then obtain the identifier of the next-level object (hereinafter referred to as the second object) of the first object in the path information. That is, in the relation partition table corresponding to the first object, obtain the identifier of the second object in the parent-child relationship corresponding to the identifier of the first object and the name of the second object. Determine whether the second object is the target object in the path information; if yes, determine the identifier of the second object as the identifier of the target object; if not, repeat the above operation to continue obtaining the identifier of the next-level object in the path information until the identifier of the target object is obtained.

[0065] In all embodiments of this application, each relational partition table can correspond to at least one directory for storing the parent-child relationship between the corresponding directory and the objects therein.

[0066] For example, the identifiers of at least one directory corresponding to each relational partition table can be within the same value range. For instance, the value range of the directory identifiers corresponding to the first relational partition table is 0000 to 0050; the value range of the directory identifiers corresponding to the second relational partition table is 0051 to 0100, and so on. In all embodiments involving determining the target relational partition table corresponding to the identifier of a directory, the relational partition table corresponding to the value range to which the identifier of that directory belongs can be used as the target relational partition table.

[0067] For example, the identifier of at least one directory corresponding to each relational partition table can correspond to the same encoded value. This encoded value is obtained by a preset algorithm (e.g., a hash algorithm). In all embodiments involving determining the target relational partition table corresponding to a directory (e.g., the parent directory of the target object), the preset algorithm can be used to determine the encoded value corresponding to the identifier of the directory; the relational partition table corresponding to the encoded value in at least two relational partition tables is determined as the target relational partition table.

[0068] The above are only examples of possible implementation methods; other examples will not be listed one by one.

[0069] In all embodiments of this application, metadata for the distributed file system can be managed using a database. A database, simply put, can be viewed as an electronic filing cabinet—a place to store electronic files, where users can perform operations such as adding, querying, updating, and deleting data. A "database" is a collection of data stored together in a certain way, shared by multiple users, with minimal redundancy, and independent of applications. A Database Management System (DBMS) is a computer software system designed to manage databases, generally possessing basic functions such as storage, retrieval, security, and backup. Database management systems can be categorized based on the database model they support, such as relational or XML (Extensible Markup Language); or based on the type of computer they support, such as server clusters or mobile devices; or based on the query language used, such as SQL (Structured Query Language) or XQuery; or based on performance priorities, such as maximum scale or highest operating speed; or other classification methods. Regardless of the classification method used, some DBMSs can cross categories, for example, supporting multiple query languages ​​simultaneously.

[0070] In all embodiments of this application, a relational database can be used to store and manage file system metadata. A relational database typically includes multiple interconnected tables, each containing related, interconnected data, and the relationships between that data to form a complete description of the file system metadata.

[0071] In this application, file system metadata is stored using a tree structure. Figure 2B is a schematic diagram of the directory tree of file system metadata in an embodiment of this application. As shown in Figure 2B, the top level of the directory tree is the root node. There is usually only one root node in the directory tree, and the root node corresponds to the root directory. As shown in Figure 2B, the root node corresponds to the root directory " / ". In the file system, there are generally two types of objects: file objects and directory objects. File objects are the objects corresponding to files that store data. For example, the file "a.dat" shown in Figure 2B corresponds to a file object. Directory objects are objects used to represent the directory hierarchy. For example, "tmp" shown in Figure 2B is a directory object; it is a subdirectory of the root directory and the parent directory of the "a.dat" file object.

[0072] In the embodiments of this application, the directory relationships in the directory structure are stored separately; that is, the branch relationships between edges or nodes in the tree structure of Figure 2B and the node attribute data are stored separately. For example, the nodes in the example of Figure 2B include:

[0073] The inode of the root directory " / ", with inode_id = 1;

[0074] The inode of the directory "home" has the node identifier inode_id = 2;

[0075] The inode of the file "a.dat" has an inode identifier inode_id = 3;

[0076] The inode of the directory "tmp", with inode_id = 4;

[0077] The inode of the directory "usr" has the node identifier inode_id = 5.

[0078] Each edge is represented in the form of (parent node identifier, child node (child) name, child node identifier). The edges in the example in Figure 2B include:

[0079] Edge (1, "home", 2), parent directory node identifier inode_id = 1, child name "home", corresponding node identifier inode_id = 2;

[0080] Edge (1, "tmp", 4), parent directory node identifier inode_id = 1, child name "tmp", corresponding node identifier inode_id = 4;

[0081] Edge (1, "usr", 5), parent directory node identifier inode_id = 1, child name "usr", corresponding node identifier inode_id = 5;

[0082] Edge (4, "a.dat", 3), parent directory node identifier inode_id = 4, child name "a.dat", corresponding node identifier inode_id = 3.

[0083] The file system accesses and manages entity attributes and directory relationships through the node's identifier ID, the parent directory node identifier of the edge, and the directory name.

[0084] Figure 3 illustrates a flowchart of a file system metadata management method according to an embodiment of this application. This file system metadata management method can be executed by a computing device with computing processing capabilities, such as a server or terminal device of a distributed file system or metadata management device. The computing device has a communication connection with at least two storage devices. The at least two storage devices store a metadata relationship table and a metadata entity table. Each metadata entity is the metadata of an object in the file system, where the object is a file or directory. The metadata relationship table stores the parent-child relationships between objects in the file system (i.e., the relationship between a parent directory and its subdirectories or files, also known as path relationships). The metadata entity table stores the entity attribute information of each metadata entity. Referring to Figure 3, the file system metadata management method includes at least steps S310 to S330.

[0085] Step S310: Obtain a path resolution request for the target object. The target object is a file (target file) or directory (target directory) from which information is expected to be obtained, and the path resolution request includes the path information of the target object.

[0086] In this embodiment, the target object is one of two types of objects in the file system: a file or a directory. A file is typically used to store data, while a directory is a hierarchy of directories used to store files. In some embodiments, a directory is referred to as a folder in the file system. It is understood that in actual implementations, depending on the specific implementation of the file system, the target object can also be a file category from other file systems. A path resolution request is typically a request initiated by an application to the file system, usually for a specified file or directory, to obtain the metadata of that file or directory for display. For example, an application might want to display the attributes of a file or a directory. The path resolution request includes the path information of the target object. This path information typically includes the access path of the target object in the file system. For example, it may include the path (full or partial path) of the directory (parent directory) where the target object is located and the name of the target object (directory name or file name). For example, the path information of the folder tmp in the root directory could be " / tmp", or the path information of the file a.dat in the folder tmp could be " / tmp / a.dat". It's understandable that when the path information is an absolute path, it includes the complete directory hierarchy from the root directory of the file system to the target object. Conversely, when the path information is a relative path, it only includes the directory hierarchy from the current context to the target object. For example, for a target file b.dump, its absolute path could be " / tmp / data / u / b.dump", while for a relative path, if the current context is " / tmp / data / ", its path would be "u / b.dump".

[0087] Step S320: Based on the path information and the metadata entity identifier of the root directory in the file system, obtain the target entity identifier of the target object's metadata entity from the metadata relationship table of the metadata database. The metadata relationship table includes the parent-child relationships between objects in the metadata entity table of the metadata database, and the metadata entity table of the metadata database includes the metadata (also called metadata entities) of each object, such as the attribute information of each object.

[0088] In this step, the identifier of the target object can be obtained from the parent-child relationship corresponding to the parent directory of the target object in the path information in the metadata relationship table.

[0089] The metadata management device retrieves the identifier of the target object (also known as the target entity identifier of the target object's metadata entity) from the metadata relationship table of the metadata database based on the path information and the identifier of the file system root directory (also known as the root directory metadata entity identifier). In the file system, the root directory metadata entity identifier is usually a preset, fixed value, such as fixed at number 1. The metadata management device can directly obtain the root directory metadata entity identifier. The metadata database is a database used to store and manage file system metadata, which typically includes a metadata relationship table and a metadata entity table. The metadata entity table includes the metadata entities corresponding to each object in the file system, such as the metadata of files or directories in the file system. The metadata relationship table includes the correspondence between various metadata entities, that is, the hierarchical relationship between directories and the inclusion relationship between directories and files.

[0090] Table 1 is an example of the metadata entity table corresponding to the directory tree shown in Figure 2B.

[0091] Table 1, Metadata Entity Table

[0092] As shown in Table 1, the metadata entity table uses the entity identifier inode_id as the primary key to distinguish different metadata entities. The entity attribute information corresponding to each metadata entity includes the entity type (directory dir or file), modification time mtime, and permissions perm, etc. It is worth noting that in this embodiment, the metadata entity table does not include the name of the corresponding file or directory; it only uses the entity identifier to identify each metadata entity.

[0093] Table 2 is an example of the metadata relationship table corresponding to the directory tree shown in Figure 2B.

[0094] Table 2, Metadata Relationship Table

[0095] As shown in Table 2, a parent-child relationship includes the entity identifier of the parent directory and the entity identifier of the subdirectory or file. The "name" element in each parent-child relationship is the name of the corresponding subdirectory or file. It is evident that the name of each object exists in only one entry in the metadata relationship table. Therefore, when renaming a file or directory, only the name of the corresponding parent-child relationship in the metadata relationship table needs to be modified. The metadata management device retrieves the target entity identifier of the target object's metadata entity from the metadata relationship table. For example, if the path information is " / tmp," meaning accessing the folder "tmp" under the root directory " / ", the metadata management device will query the metadata relationship table for the parent directory entity identifier parent_id of 1 and the path name "tmp," and retrieve the target entity identifier of 4 from that parent-child relationship.

[0096] Step S330: Based on the target entity identifier, read the target entity attribute information of the target object metadata entity from the metadata entity table.

[0097] The metadata management device can read the metadata of the target object (also known as the target entity attribute information of the metadata entity) from the metadata entity table based on the target entity identifier. For example, by searching the metadata entity table based on inode_id=4, the entity attribute information {dir, mtime, perm…} of the metadata entity with inode_id=4 can be found.

[0098] In the embodiments of this application, after obtaining a path resolution request for a target object, the metadata management device retrieves the target entity identifier of the target object's metadata entity from the metadata relationship table based on the path information and the root directory metadata entity identifier of the file system root directory. Then, based on the target entity identifier, it reads the target entity attribute information of the target object's metadata entity from the metadata entity table. In this way, the file system metadata is stored separately in the metadata relationship table and the metadata entity table. When the amount of metadata is very large and cannot be stored on a single machine, the metadata relationship table and the metadata entity table can be stored in different storage devices, thereby reducing the requirement for single-machine storage and supporting the storage and management of larger amounts of metadata.

[0099] In all embodiments of this application, the metadata relationship table and metadata entity table can be managed using database technology. The metadata database stores the metadata relationship table and metadata entity table. The metadata database can be stored on at least two physical storage devices. By storing the file system metadata in the metadata entity table and metadata relationship table within the metadata database, when path resolution of a file or directory is required, the corresponding path information and entity information are obtained by querying the corresponding table in the metadata database. This allows for independent management of the file system metadata using the database. In this way, metadata management and storage no longer occupy the file system's memory or disk space, ensuring that the growth of the file system metadata is not affected or constrained by the file system's memory or local disk capacity, thereby improving the file system's data carrying capacity and operating efficiency.

[0100] In all embodiments of this application, based on the technical solutions in this application, the metadata management device also obtains a path setting request for a target object. The setting request includes the target object's path information to be updated and the target path information. Then, based on the parent directory entity identifier and the object name of the target object in the path information to be updated, the device queries the metadata relationship table for the target entity identifier of the target object's metadata entity. Finally, the metadata management device updates the parent-child relationship between the target object's metadata entity and the parent directory's metadata entity in the metadata relationship table based on the target entity identifier and the target path information. In this embodiment, the path setting request can specifically be a name modification request, such as a file name modification request for a file object or a directory name modification request for a directory object. The path information to be updated is typically the metadata entity identifier and name of the original parent directory of the target directory, while the target path information is the metadata entity identifier and name of the new parent directory. During execution, the metadata management device first queries the metadata relationship table to obtain the target entity identifier of the target directory, and then updates the parent-child relationship between the target object's metadata entity and the parent directory's metadata entity in the metadata relationship table based on the target entity identifier and the target path information. Specifically, for example, a path setting request could be `rename(1, "tmp", 1, "data")`, which means renaming "tmp" from its parent directory " / " (inode_id=1) to "data" under the parent directory " / " (inode_id=1). During execution, the metadata management device first finds the inode_id of the tmp directory as 4 based on inode_id=1 and name=tmp, and then updates the name in the parent-child relationship table where parent_id=1 and node_id=4 to "data". In this embodiment, when updating path information, only the corresponding path name in the metadata relationship table needs to be modified. Compared to modifying both the metadata entity table and the metadata relationship table simultaneously, this reduces the number of data tables involved in path setting, thereby improving the execution efficiency of path setting.

[0101] In all embodiments of this application, based on the technical solutions of this application, during the process of updating the parent-child relationship between the target object metadata entity and the parent directory metadata entity in the metadata relationship table according to the target entity identifier and the target path information, the metadata management device deletes the parent-child relationship between the parent directory metadata entity and the target object metadata entity from the metadata relationship table according to the parent directory entity identifier and the object name of the target object in the path information to be updated. Then, based on the target entity identifier, the target parent directory entity identifier in the target path information, and the target object name, it creates a new parent-child relationship between the parent directory metadata entity and the target object metadata entity in the metadata relationship table. Specifically, in this embodiment, the metadata management device first deletes the parent-child relationship between the parent directory metadata entity and the target object metadata entity in the metadata relationship table, and then establishes a new parent-child relationship between the parent directory metadata entity and the target object metadata entity based on the target path information. Specifically, taking the path setting request mentioned above as an example, the metadata management device first initiates a transaction in the metadata database, then searches the metadata relationship table for a parent directory entity with a parent_id of 1 and a name of tmp, thus obtaining the inode_id of the tmp directory as 4. Subsequently, it deletes the parent-child relationship with a parent_id of 1 and a name of tmp from the metadata relationship table, and then inserts a new parent-child relationship with a parent_id of 1, a name of data, and an inode_id of 4 into the metadata relationship table, thereby establishing the parent-child relationship between the root directory and the "data" directory. It is understood that in the above method, the parent directory entity identifier in the path information to be updated and the parent directory entity identifier in the target path information can be different. In this case, after executing the path setting, it can be considered that the data folder has been moved to a new parent directory, for example, it can be moved from the root directory to the usr directory. In all embodiments, after the new path is established, the metadata management device updates the modification time mtime in the metadata entity corresponding to the parent directory node in the metadata entity table, thereby recording the time of the update. Finally, the metadata management device commits the transaction, causing the data update to be recorded in the metadata database. In this embodiment, during the path setting process, the original parent-child relationship is deleted and a new parent-child relationship is established, thereby ensuring that the original parent-child relationship is completely cleared, avoiding data inconsistency problems that may be caused by updating data, and thus improving the data accuracy in the file system.

[0102] In all embodiments of this application, based on the technical solutions in this application, the metadata management device also obtains an object deletion request for the target object. The object deletion request includes the deletion path information of the target object. Subsequently, based on the parent directory entity identifier and the target object name in the deletion path information, the device queries the target entity identifier of the target object metadata entity from the metadata relationship table, and deletes the parent-child relationship between the parent directory metadata entity and the target object metadata entity from the metadata relationship table. Finally, based on the target entity identifier, the device deletes the target object metadata entity from the metadata entity table. In this embodiment, when deleting an object, the metadata management device first finds the target entity identifier of the target object to be deleted based on the parent directory entity identifier and the target object name in the deletion path information, and deletes the corresponding parent-child relationship. Then, it deletes the corresponding metadata entity from the metadata entity table based on the target entity identifier, thereby ensuring that the relevant information of the object to be deleted is completely deleted, avoiding redundant information from occupying database space.

[0103] In all embodiments of this application, based on the technical solution of this application, the metadata management device also obtains a subdirectory read request for a target parent directory. The subdirectory read request includes the directory path information of the target parent directory. Then, based on the directory names of each directory level and the root directory metadata entity identifier included in the directory path information, the target entity identifier of the target parent directory metadata entity is obtained from the metadata relationship table. Then, based on the target entity identifier, each subdirectory metadata entity that has a parent-child relationship with the target parent directory metadata entity is read from the metadata relationship table, resulting in the subdirectory name and the corresponding subdirectory entity identifier of each subdirectory. In this embodiment, reading the subdirectory name and subdirectory entity identifier of each subdirectory through the target entity identifier of the target parent directory metadata entity and the parent-child relationship with that target parent directory metadata entity provides a concrete implementation method for reading all child objects of a specified directory, which is beneficial to improving the operability of the solution.

[0104] In this application, other embodiments that refine the technical solution of the embodiment shown in FIG3 are also proposed, as shown in FIG4. In a file system metadata management method of one embodiment of this application, the metadata entity table includes multiple entity partition tables. The solution of this application may include the following steps:

[0105] Step S410: Obtain the path resolution request of the target object, wherein the target object is a target file or a target directory, and the path resolution request includes the path information of the target object.

[0106] In all embodiments, the implementation details of step S410 are consistent with those of step S310 shown in FIG3, and will not be repeated here.

[0107] Step S420: Based on the path information and the root directory metadata entity identifier of the file system root directory, obtain the target entity identifier of the target object metadata entity from the metadata relationship table of the metadata database. The metadata relationship table includes the parent-child relationship between object metadata entities in the metadata entity table of the metadata database, and the metadata entity table of the metadata database includes the entity attribute information of the object metadata entities.

[0108] In all embodiments, the implementation details of step S420 are consistent with those of step S320 shown in FIG3, and will not be repeated here.

[0109] Step S430: Based on the target entity identifier, determine the target entity partition table corresponding to the target object metadata entity and the storage address of the target entity partition table;

[0110] Step S440: Based on the storage address of the target entity partition table and the target entity identifier, read the target entity attribute information of the target object metadata entity from the target entity partition table.

[0111] In this embodiment, the metadata entity table includes multiple entity partition tables. Each entity partition table (also referred to as a partition) is a subset of data in the metadata entity table. Different subsets of data in the metadata entity table are logically isolated; that is, different entity partition tables, regardless of whether they are stored on the same physical machine, can be processed independently (e.g., storage, reading, modification, etc.). In a distributed cluster, different partitions are usually distributed across different physical nodes (machines) to achieve storage expansion, load balancing, and fault isolation. It can be understood that the data included in each entity partition table is different from each other and can be deployed to different database servers or cloud servers. The metadata management device can determine the target entity partition table and the storage address of the target entity partition table corresponding to the target object's metadata entity based on the target entity identifier of the target object. The metadata management device can calculate the corresponding target entity partition table number based on a preset hash algorithm, and the storage address of each entity partition table can be pre-stored on the file system server. Specifically, please refer to Figure 5, which is a schematic diagram of the metadata entity table and entity partition table in this embodiment. As shown in Figure 5, the logical table of the metadata entity table is a complete table, but it is actually divided into two physical tables, which are typically stored on different physical devices. The metadata management device determines which entity partition table a metadata entity belongs to based on its entity identifier, and each entity partition table stores different data. After determining the target entity partition table, the metadata management device can read the target entity attribute information of the target object metadata entity from the target entity partition table based on its storage address and the target entity identifier. This method allows the file system to store file system metadata in different data tables, thus distributing it across different devices. This enables the metadata management system to store and manage file system metadata across multiple devices when dealing with large amounts of data, facilitating horizontal scaling of metadata storage capacity and improving the flexibility and scalability of the metadata management solution.

[0112] In the embodiments of this application, after obtaining a path resolution request for a target object, the metadata management device retrieves the target entity identifier of the target object's metadata entity from the metadata relationship table of the metadata database based on the path information and the root directory metadata entity identifier of the file system's root directory. The metadata relationship table includes the parent-child relationships between object metadata entities in the metadata entity table of the metadata database, and the metadata entity table also includes the entity attribute information of the object metadata entities. Then, based on the target entity identifier, the target entity attribute information of the target object's metadata entity is read from the metadata entity table. Through this method, by storing the file system's metadata in the metadata entity table and metadata relationship table of the metadata database, when path resolution of a file or directory is required, the corresponding path information and entity information are obtained by querying the corresponding table in the metadata database. This allows for independent management of the file system's metadata using the database. Metadata management and storage no longer occupy the file system's memory or disk space, ensuring that the growth of the file system's metadata is not affected or constrained by the file system's memory or local disk capacity, thereby improving the file system's data carrying capacity and operating efficiency.

[0113] In the embodiments of this application, other embodiments that refine the technical solution of the embodiment shown in FIG3 are also proposed. Specifically, as shown in FIG6, in a file system metadata management method of one embodiment of this application, the metadata relationship table includes multiple relationship partition tables. The solution of this application may include the following steps:

[0114] Step S610: Obtain the path resolution request of the target object, wherein the target object is a target file or a target directory, and the path resolution request includes the path information of the target object.

[0115] In all embodiments, the implementation details of step S610 are consistent with those of step S310 shown in FIG3, and will not be repeated here.

[0116] Step S620: Based on the root directory metadata entity identifier of the file system root directory and the parent directory name of the target object in the path information, query the parent directory entity identifier of the target object.

[0117] Step S630: Determine the target relationship partition table corresponding to the target object and the storage address of the target relationship partition table based on the parent directory entity identifier of the target object;

[0118] Step S640: Based on the storage address of the target relationship partition table, the parent directory name, and the parent directory entity identifier, query the target parent-child relationship between the target object metadata entity and the parent directory metadata entity from the relationship partition table, so as to read the target entity identifier of the target object metadata entity in the target parent-child relationship. The metadata relationship table includes the parent-child relationship between object metadata entities in the metadata entity table of the metadata database, and the metadata entity table of the metadata database includes the entity attribute information of the object metadata entities.

[0119] In this embodiment, the metadata relationship table includes multiple relationship partition tables. Each relationship partition table includes different parent-child relationships and can be deployed to different database servers or cloud servers. The metadata management device determines the storage address of the corresponding relationship partition table and the target relationship partition table based on the parent directory entity identifier in each parent-child relationship. The parent directory entity identifier can be obtained by querying the root directory metadata entity identifier and the parent directory name of the target object in the path information. Specifically, if there are multiple levels of directories, there may be other directory levels between the parent directory of the target object and the root directory. The metadata management device will query level by level from the root directory according to the directory level until the parent directory entity identifier of the target object is found. After determining the target relationship partition table, the metadata management device can query the target parent-child relationship between the target object metadata entity and the parent directory metadata entity from the relationship partition table based on the storage address of the target relationship partition table, the parent directory name, and the parent directory entity identifier, so as to read the target entity identifier of the target object metadata entity in the target parent-child relationship. Specifically, please refer to Figure 7, which is a schematic diagram of the metadata relationship table and the relationship partition table in this embodiment of the application. As shown in Figure 7, the logical table of the metadata relational table is a complete table containing all data. The logical table is actually divided into two physical tables, namely relational partition tables. Each relational partition table (also simply called a partition) is a subset of data in the metadata relational table. Different subsets of data in the metadata relational table are logically isolated; that is, different relational partition tables, regardless of whether they are stored on the same physical machine, can be stored and computed independently. In a distributed cluster, different partitions are typically distributed across different physical nodes (machines) to achieve storage expansion, load balancing, and fault isolation. The two physical tables can be stored on different database servers. The metadata management device determines the relational partition table to which the parent-child relationship belongs based on the parent directory entity identifier `parent_id` in the metadata relational table. In a specific query, for example, if the metadata management device wants to query the parent-child relationship of file `a.dat`, it will query its parent directory entity identifier `parent_id` as 4 based on its parent directory `tmp`, then determine the physical table based on `parent_id`, and then access the database where the physical table resides to query the target entity identifier of file `a.dat` as 3 based on `parent_id = 4` and the filename `name = a.dat`. In this embodiment, the metadata management device determines the relational partition table to which the parent-child relationship belongs by using the parent directory entity identifier in the parent-child relationship. This ensures that the parent-child relationships of various subdirectories or files under the same parent directory belong to the same relational partition table, thereby avoiding read amplification that may occur when reading data due to data being placed in different relational partition tables under the same directory. This prevents excessive latency in the data reading process and helps ensure efficient reading of file metadata.

[0120] Step S650: Based on the target entity identifier, read the target entity attribute information of the target object metadata entity from the metadata entity table.

[0121] In all embodiments, the implementation details of step S650 are consistent with those of step S330 shown in FIG3, and will not be repeated here.

[0122] In the embodiments of this application, after obtaining a path resolution request for a target object, the metadata management device retrieves the target entity identifier of the target object's metadata entity from the metadata relationship table of the metadata database based on the path information and the root directory metadata entity identifier of the file system's root directory. The metadata relationship table includes the parent-child relationships between object metadata entities in the metadata entity table of the metadata database, and the metadata entity table also includes the entity attribute information of the object metadata entities. Then, based on the target entity identifier, the target entity attribute information of the target object's metadata entity is read from the metadata entity table. Through this method, by storing the file system's metadata in the metadata entity table and metadata relationship table of the metadata database, when path resolution of a file or directory is required, the corresponding path information and entity information are obtained by querying the corresponding table in the metadata database. This allows for independent management of the file system's metadata using the database. Metadata management and storage no longer occupy the file system's memory or disk space, ensuring that the growth of the file system's metadata is not affected or constrained by the file system's memory or local disk capacity, thereby improving the file system's data carrying capacity and operating efficiency.

[0123] In the embodiments of this application, other embodiments that refine the technical solution of the embodiment shown in FIG3 are also proposed, as shown in FIG8. In a file system metadata management method of one embodiment of this application, the solution of this application may include the following steps:

[0124] Step S810: Obtain the object creation request of the target object, wherein the object creation request includes the target object's path information to be created and entity attribute information;

[0125] Step S820: Based on the target entity identifier and the entity attribute information of the target object in the path information to be created, create the target object metadata entity in the metadata entity table. The target object metadata entity includes the entity attribute information.

[0126] Step S830: Based on the target entity identifier and the object name and parent directory entity identifier of the target object in the path information to be created, create a parent-child relationship between the parent directory metadata entity and the target object metadata entity in the metadata relationship table.

[0127] In this embodiment, when creating a new target object, the metadata management device creates a corresponding target object metadata entity in the metadata entity table and establishes a parent-child relationship between the target object metadata entity and its parent directory metadata entities in the metadata relationship table. Specifically, the object creation request obtained by the metadata management device includes the target object's creation path information and entity attribute information. The creation path information includes the parent directory entity identifier of the target object's parent directory metadata and the target object's object name, i.e., the directory in which the object is created and the filename or folder name of the created object. The object creation request also includes the target entity identifier and entity attribute information of the target object. The target entity identifier is usually determined based on existing entity identifiers in the metadata database; for example, the metadata management device generates a target entity identifier for a newly created metadata entity using a serial number. The metadata management device can insert the target object metadata entity into the metadata entity table and the corresponding parent-child relationship into the metadata relationship table through database insertion operations.

[0128] Step S840: Obtain the path resolution request of the target object, wherein the target object is a target file or a target directory, and the path resolution request includes the path information of the target object.

[0129] In all embodiments, the implementation details of step S840 are consistent with those of step S310 shown in FIG3, and will not be repeated here.

[0130] Step S850: Based on the path information and the root directory metadata entity identifier of the file system root directory, obtain the target entity identifier of the target object metadata entity from the metadata relationship table of the metadata database. The metadata relationship table includes the parent-child relationship between object metadata entities in the metadata entity table of the metadata database, and the metadata entity table of the metadata database includes the entity attribute information of the object metadata entities.

[0131] In all embodiments, the implementation details of step S850 are consistent with those of step S320 shown in FIG3, and will not be repeated here.

[0132] Step S860: Based on the target entity identifier, read the target entity attribute information of the target object metadata entity from the metadata entity table.

[0133] In all embodiments, the implementation details of step S860 are consistent with those of step S330 shown in FIG3, and will not be repeated here.

[0134] In the embodiments of this application, after obtaining a path resolution request for a target object, the metadata management device retrieves the target entity identifier of the target object's metadata entity from the metadata relationship table of the metadata database based on the path information and the root directory metadata entity identifier of the file system's root directory. The metadata relationship table includes the parent-child relationships between object metadata entities in the metadata entity table of the metadata database, and the metadata entity table also includes the entity attribute information of the object metadata entities. Then, based on the target entity identifier, the target entity attribute information of the target object's metadata entity is read from the metadata entity table. Through this method, by storing the file system's metadata in the metadata entity table and metadata relationship table of the metadata database, when path resolution of a file or directory is required, the corresponding path information and entity information are obtained by querying the corresponding table in the metadata database. This allows for independent management of the file system's metadata using the database. Metadata management and storage no longer occupy the file system's memory or disk space, ensuring that the growth of the file system's metadata is not affected or constrained by the file system's memory or local disk capacity, thereby improving the file system's data carrying capacity and operating efficiency.

[0135] In all embodiments of this application, based on the technical solutions of this application, the metadata entity table includes a file metadata entity, and the metadata relationship table includes multiple relationship partition tables, which further include directory metadata entities. During the process of creating the target object metadata entity in the metadata entity table according to the target entity identifier and entity attribute information of the target object in the path information to be created, if the target object is a file object, the metadata management device creates the target object metadata entity in the metadata entity table. If the target object is a directory object, the metadata management device determines the target relationship partition table corresponding to the target object based on the parent directory entity identifier of the target object in the path information to be created. Subsequently, the metadata management device creates the target object metadata entity in the relationship partition table according to the target entity identifier and entity attribute information of the target object in the path information to be created, and updates the entity update record of the parent directory metadata entity in the relationship partition table according to the parent directory entity identifier of the target object. In this embodiment, the data in the metadata relationship table is further expanded. Specifically, according to the specific type of the target object, the metadata entities are divided into file metadata entities and directory metadata entities. In this system, file metadata entities are stored in a metadata entity table, while directory metadata entities are stored in a relation partition table along with their corresponding parent-child relationships. Specifically, similar to parent-child relationships, the metadata management device can determine the relation partition table corresponding to a directory metadata entity based on its entity identifier, thereby storing the directory metadata entity and all parent-child relationships with that directory as the parent directory in the same relation partition table. See Figure 9 for details; Figure 9 is a schematic diagram of the relation partition table extension scheme in this embodiment. As shown in Figure 9, additional data columns for storing directory metadata entities and for identifying metadata entity types are added to both the metadata relation table and the relation partition table. It can be seen that the directory metadata entity of the root directory and the parent-child relationships of each subdirectory of the root directory are in the same physical table. Similarly, the metadata entity of the tmp directory and its parent-child relationship with the file a.dat in that directory are also in the same physical table. That is, the directory metadata entity with entity identifier parent_id of 1 and its parent-child relationship data are in the same physical table. Likewise, the directory metadata entity with entity identifier parent_id of 4 and its parent-child relationship data are also in the same physical table. Directory metadata entities with parent_id values ​​of 2 and 5 are assigned to their respective physical tables based on the hash calculation result of parent_id. Furthermore, when creating the target object metadata entity, if the target object's metadata entity is a file object, it can be created directly in the metadata entity table.It is understandable that if the metadata entity table includes multiple entity partition tables, it is also necessary to similarly determine the entity partition table corresponding to the file object and create the file object's metadata entity in the determined entity partition table. If the target object is a directory object, the corresponding target relationship partition table is determined based on the parent directory entity identifier, and then the target object's metadata entity is created in the target relationship partition table. In this embodiment, the entity update record of the parent directory metadata entity is further updated in the relationship partition table based on the parent directory entity identifier of the target object. It is understood that in the embodiments of this application, as long as there is a data update in the metadata relationship table or the relationship partition table, the entity update record of the corresponding parent directory metadata entity can be updated. The specific process can be adjusted according to the storage location of the parent directory metadata entity. For example, if the parent directory metadata entity is stored in the metadata entity table, then the update process in the metadata entity table is referred to. By placing the directory metadata of the parent directory and its parent-child relationship in the same relationship partition table, it is not necessary to query the metadata entity table when obtaining directory attributes, thereby reducing the number of transactions that perform cross-partition queries and improving the write performance of file system metadata management.

[0136] In all embodiments of this application, based on the technical solution of this application, the metadata entity table includes multiple entity partition tables. During the process of reading the target entity attribute information of the target object metadata entity from the metadata entity table according to the target entity identifier, if the target object is a directory object, the metadata management device reads the target entity attribute information of the target object metadata entity from the entity partition table corresponding to the file object according to the target entity identifier. If the target object is a file object, the metadata management device reads the target entity attribute information of the target object metadata entity from the metadata entity table. In this embodiment, the metadata entity table includes multiple entity partition tables. When reading target entity attribute information from the metadata entity table, if the target object is a directory object, the metadata management device will first read the target entity attribute information of the target object metadata entity from the entity partition table according to the target entity identifier. In this embodiment, both the metadata entity table and the metadata relationship table are divided into multiple specific partition tables, thereby enabling the file system metadata to be distributed and stored on different database servers, further improving the scalability of the file system metadata management solution when facing large amounts of data.

[0137] In all embodiments of this application, based on the technical solutions of this application, the metadata management device obtains a directory deletion request for a directory object to be deleted. The directory deletion request includes the deletion path information of the directory object to be deleted. Then, based on the parent directory entity identifier of the directory object to be deleted in the deletion path information, the target relationship partition table corresponding to the directory object to be deleted is determined. Next, the metadata management device queries the deletion entity identifier of the metadata entity to be deleted from the target relationship partition table based on the parent directory entity identifier in the deletion path information and the target directory name of the directory object to be deleted. Based on the deletion entity identifier, the device deletes the parent-child relationship between the parent directory metadata entity and the metadata entity to be deleted from the target relationship partition table and deletes the metadata entity to be deleted.

[0138] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0139] The following describes the implementation of the apparatus of this application, which can be used to execute the cloud host environment configuration method in the above embodiments of this application. Figure 10 schematically shows a block diagram of the file system metadata management apparatus in an embodiment of this application. The file system metadata management apparatus has a communication connection with at least two storage devices. The at least two storage devices store a metadata relationship table and a metadata entity table. The metadata entity table stores the metadata of each object in the file system, where the object is a file or a directory. The metadata relationship table stores the parent-child relationships between objects in the file system. As shown in Figure 10, the file system metadata management apparatus 1000 mainly includes the following modules.

[0140] The request acquisition module 1010 is used to acquire a path resolution request for a target object, wherein the target object is a target file or a target directory, and the path resolution request includes the path information of the target object;

[0141] The object acquisition module 1020 is configured to, in response to the path resolution request, obtain the identifier of the target object from the parent-child relationship corresponding to the path information in the metadata relationship table. For example, based on the path information and the root directory metadata entity identifier of the file system root directory, the target entity identifier of the target object metadata entity is obtained from the metadata relationship table of the metadata database, wherein the metadata relationship table includes the parent-child relationship between object metadata entities in the metadata entity table of the file system metadata, and the metadata entity table of the file system metadata includes the entity attribute information of the object metadata entities;

[0142] The information reading module 1030 is used to obtain the metadata corresponding to the identifier of the target object from the metadata entity table. For example, based on the target entity identifier, it reads the target entity attribute information of the target object metadata entity from the metadata entity table.

[0143] In all embodiments of this application, the metadata entity table consists of at least two entity partition tables stored in the at least two storage devices. Each entity partition table corresponds to at least one object in the file system and stores the metadata of the corresponding object. The information reading module 1030 can be used to determine the target entity partition table corresponding to the identifier of the target object, and to read the metadata corresponding to the identifier of the target object from the target entity partition table.

[0144] In all embodiments of this application, the information reading module configuration 1030 can be used to determine the encoding value corresponding to the target entity identifier using a preset algorithm; and to determine the entity partition table corresponding to the encoding value as the target entity partition table.

[0145] In all embodiments of this application, the metadata relationship table consists of at least two relationship partition tables stored in the at least two storage devices. Each of the at least two relationship partition tables corresponds to at least one directory in the file system and stores the parent-child relationship between the corresponding directory and its subdirectories or files. The object acquisition module configuration 1020 is used to obtain the identifier of the target object from the target relationship partition table corresponding to the parent directory of the target object in the path information from the at least two relationship partition tables.

[0146] In all embodiments of this application, each parent-child relationship in each of the at least two relational partition tables includes an identifier of a directory and the name and identifier of an object in that directory. The object acquisition module 1020 can be used to: determine the identifier of the parent directory of the target object in the at least two relational partition tables based on the identifier of the root directory of the preset file system and the name of at least one directory in the path information; determine the target relational partition table corresponding to the identifier of the parent directory in the at least two relational partition tables; and read the identifier of the target object from the parent-child relationships in the target relational partition table that include the identifier of the parent directory and the name of the target object in the path information.

[0147] In all embodiments of this application, the object acquisition module 1020 can be used to: determine the encoding value corresponding to the identifier of the parent directory using a preset algorithm; and determine the relationship partition table corresponding to the encoding value in the at least two relationship partition tables as the target relationship partition table.

[0148] In all embodiments of this application, the metadata entity table includes multiple entity partition tables; the information reading module 1030 is specifically configured to: determine the target entity partition table corresponding to the target object metadata entity and the storage address of the target entity partition table according to the target entity identifier; and read the target entity attribute information of the target object metadata entity from the target entity partition table according to the storage address of the target entity partition table and the target entity identifier.

[0149] In all embodiments of this application, the metadata relationship table includes multiple relationship partition tables; the object acquisition module 1020 can be used to query the parent directory entity identifier of the target object based on the root directory metadata entity identifier of the file system root directory and the parent directory name of the target object in the path information; determine the target relationship partition table corresponding to the target object and the storage address of the target relationship partition table based on the parent directory entity identifier of the target object; query the target parent-child relationship between the target object metadata entity and the parent directory metadata entity from the relationship partition table based on the storage address of the target relationship partition table, the parent directory name and the parent directory entity identifier, so as to read the target entity identifier of the target object metadata entity in the target parent-child relationship.

[0150] In all embodiments of this application, the file system metadata management device further includes a path setting module, configured to obtain a path setting request for a target object, wherein the setting request includes the target object's path information to be updated and target path information; query the target entity identifier of the target object's metadata entity from the metadata relationship table based on the parent directory entity identifier in the path information to be updated and the object name of the target object; and update the parent-child relationship between the target object's metadata entity and the parent directory metadata entity in the metadata relationship table based on the target entity identifier and the target path information.

[0151] In all embodiments of this application, the path setting module can be used to: delete the parent-child relationship between the parent directory metadata entity and the target object metadata entity from the metadata relationship table based on the parent directory entity identifier and the object name of the target object in the path information to be updated; and create the parent-child relationship between the parent directory metadata entity and the target object metadata entity in the metadata relationship table based on the target entity identifier, the target parent directory entity identifier and the target object name in the target path information.

[0152] In all embodiments of this application, the file system metadata management device further includes an object deletion module, configured to obtain an object deletion request for the target object, the object deletion request including the target object's path information to be deleted; query the target entity identifier of the target object's metadata entity from the metadata relationship table based on the parent directory entity identifier and the target object name in the path information to be deleted, and delete the parent-child relationship between the parent directory metadata entity and the target object's metadata entity from the metadata relationship table; and delete the target object's metadata entity from the metadata entity table based on the target entity identifier.

[0153] In all embodiments of this application, the file system metadata management device further includes an object creation module, configured to obtain an object creation request for the target object, wherein the object creation request includes the target object's path information to be created and entity attribute information; create a target object metadata entity in the metadata entity table based on the target entity identifier of the target object in the path information to be created and the entity attribute information, wherein the target object metadata entity includes the entity attribute information; and create a parent-child relationship between the parent directory metadata entity and the target object metadata entity in the metadata relationship table based on the target entity identifier and the target object's object name and parent directory entity identifier in the path information to be created.

[0154] In all embodiments of this application, the metadata entity table includes a file metadata entity, the metadata relationship table includes multiple relationship partition tables, and the relationship partition table further includes a directory metadata entity; the object creation module is specifically configured to: if the target object is a file object, then create the target object metadata entity in the metadata entity table; if the target object is a directory object, then determine the target relationship partition table corresponding to the target object according to the parent directory entity identifier of the target object in the path information to be created; create the target object metadata entity in the relationship partition table according to the target entity identifier and the entity attribute information of the target object in the path information to be created, and update the entity update record of the parent directory metadata entity in the relationship partition table according to the parent directory entity identifier of the target object.

[0155] In all embodiments of this application, the metadata entity table includes multiple entity partition tables; the information reading module 1030 is specifically configured to: if the target object is a directory object, then read the target entity attribute information of the target object metadata entity from the entity partition table corresponding to the file object according to the target entity identifier; if the target object is a file object, then read the target entity attribute information of the target object metadata entity from the metadata entity table.

[0156] In all embodiments of this application, the file system metadata management device further includes a directory deletion module, configured to: obtain a directory deletion request for a directory object to be deleted, the directory deletion request including the deletion path information of the directory object to be deleted; determine the target relationship partition table corresponding to the directory object to be deleted based on the parent directory entity identifier of the directory object to be deleted in the deletion path information; query the deletion entity identifier of the metadata entity of the directory object to be deleted from the target relationship partition table based on the parent directory entity identifier in the deletion path information and the target directory name of the directory object to be deleted; and delete the parent-child relationship between the parent directory metadata entity and the metadata entity of the directory object to be deleted, and delete the metadata entity of the directory object to be deleted, based on the deletion entity identifier.

[0157] In all embodiments of this application, the file system metadata management device further includes a subdirectory reading module, configured to: obtain a subdirectory reading request for a target parent directory, wherein the subdirectory reading request includes directory path information of the target parent directory; obtain the target entity identifier of the target parent directory metadata entity from the metadata relationship table based on the directory names of each directory level and the root directory metadata entity identifier included in the directory path information; and read each subdirectory metadata entity that has a parent-child relationship with the target parent directory metadata entity from the metadata relationship table based on the target entity identifier, thereby obtaining the subdirectory name of each subdirectory and the subdirectory entity identifier of the corresponding subdirectory metadata entity.

[0158] It should be noted that the apparatus provided in the above embodiments and the method provided in the above embodiments belong to the same concept, and the specific way in which each module performs the operation has been described in detail in the method embodiments, and will not be repeated here.

[0159] Figure 11 shows a schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application.

[0160] It should be noted that the computer system 1100 of the electronic device shown in Figure 11 is only an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0161] As shown in Figure 11, the computer system 1100 includes a Central Processing Unit (CPU) 1101, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1102 or programs loaded from Storage Unit 1108 into Random Access Memory (RAM) 1103. The RAM 1103 also stores various programs and data required for system operation. The CPU 1101, ROM 1102, and RAM 1103 are interconnected via a bus 1104. An Input / Output (I / O) interface 1105 is also connected to the bus 1104.

[0162] The following components are connected to I / O interface 1105: an input section 1106 including a keyboard, mouse, etc.; an output section 1107 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to I / O interface 1105 as needed. Removable media 1111, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1110 as needed so that computer programs read from them can be installed into storage section 1108 as needed.

[0163] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including 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 communication section 1109, and / or installed from removable medium 1111. When the computer program is executed by central processing unit (CPU) 1101, it performs various functions defined in the system of this application.

[0164] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. 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), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium that includes or stores a program, which can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, 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 transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also 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 included on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0165] 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 application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing the 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 a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may 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.

[0166] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0167] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0168] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0169] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0170] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A file system metadata management method, executed by a computing device having a communication connection with at least two memories, a metadata relationship table and a metadata entity table are stored in the at least two memories, the metadata entity table stores metadata of objects in a file system, the objects are files or directories, and the metadata relationship table stores parent-child relationships between the objects in the file system; the method comprises: obtaining a path resolution request, wherein the path resolution request comprises path information of a target object; in response to the path resolution request, obtaining an identifier of the target object from a parent-child relationship corresponding to the path information in the metadata relationship table; obtaining metadata corresponding to the identifier of the target object from the metadata entity table.

2. The method of claim 1, the metadata entity table is composed of at least two entity partition tables stored in the at least two memories, each of the at least two entity partition tables corresponds to at least one object in the file system and stores metadata of the corresponding object. The metadata corresponding to the identifier of the target object from the metadata entity table comprises: determining a target entity partition table corresponding to the identifier of the target object; obtaining metadata corresponding to the identifier of the target object from the target entity partition table.

3. The method of claim 2, wherein, The target entity partition table corresponding to the identifier of the target object comprises: determining an encoding value corresponding to the identifier of the target entity by using a preset algorithm; determining the entity partition table corresponding to the encoding value as the target entity partition table.

4. The method of any one of claims 1 to 3, wherein, The metadata relationship table is composed of at least two relationship partition tables stored in the at least two memories, each relationship partition table of the at least two relationship partition tables corresponds to at least one directory in the file system, and stores parent-child relationships between the corresponding directory and objects in the directory; wherein the identifier of the target object from the parent-child relationship corresponding to the path information in the metadata relationship table comprises: obtaining the identifier of the target object from a target relationship partition table corresponding to a parent directory of the target object in the path information in the at least two relationship partition tables.

5. The method of claim 4, wherein, Each parent-child relationship in each relationship partition table of the at least two relationship partition tables comprises an identifier of a directory and a name and identifier of an object in the directory; obtaining the identifier of the target object from a target relationship partition table corresponding to a parent directory of the target object in the path information in the at least two relationship partition tables comprises: determining the identifier of the parent directory of the target object in the at least two relationship partition tables according to a preset identifier of a root directory of the file system and a name of at least one directory in the path information; determining a target relationship partition table corresponding to the identifier of the parent directory in the at least two relationship partition tables; reading the identifier of the target object from a parent-child relationship in the target relationship partition table, the parent-child relationship comprises the identifier of the parent directory and the name of the target object in the path information.

6. The method of claim 5, wherein, The target relationship partition table corresponding to the identifier of the parent directory in the at least two relationship partition tables comprises: determining an encoding value corresponding to the identifier of the parent directory by using a preset algorithm; determining a relationship partition table corresponding to the encoding value in the at least two relationship partition tables as the target relationship partition table.

7. The method of claim 1, wherein, Each parent-child relationship in the metadata relationship table comprises an identification of a parent directory and a name and an identification of an object in the parent directory; The method further comprises: obtaining a path setting request, the setting request comprising to-be-updated path information of a target object and target path information; obtaining the identification of the target object from a parent-child relationship in the metadata relationship table corresponding to the identification of a parent directory in the to-be-updated path information and the name of the target object; updating the metadata relationship table using the identification of the target object and the target path information.

8. The method of claim 7, wherein, The updating of the metadata relationship table using the identification of the target object and the target path information comprises: deleting the parent-child relationship corresponding to the identification of the parent directory in the to-be-updated path information and the name of the target object from the metadata relationship table; creating a parent-child relationship in the metadata relationship table corresponding to the identification of the target object, the identification of a target parent directory in the target path information, and the name of the target object.

9. The method of claim 1, further comprising: obtaining an object deletion request, the object deletion request comprising to-be-deleted path information of a target object; determining the identification of the target object from a parent-child relationship in the metadata relationship table corresponding to the identification of a parent directory in the to-be-deleted path information and the name of the target object, and deleting the parent-child relationship from the metadata relationship table; deleting metadata corresponding to the identification of the target object from the metadata entity table.

10. The method of claim 1, further comprising: obtaining an object creation request, the object creation request comprising the identification of a target object, to-be-created path information, and metadata; creating an entry corresponding to the target object in the metadata entity table, the entry comprising the identification of the target object and the metadata; determining in the metadata relationship table; creating a parent-child relationship in the metadata relationship table, the parent-child relationship comprising the identification of a parent directory of the target object in the to-be-created path information, the identification and the name of the target object.

11. The method of claim 1, further comprising: obtaining a subdirectory reading request, the subdirectory reading request comprising path information of a target parent directory; obtaining the identification of the target parent directory from a parent-child relationship in the metadata relationship table corresponding to at least one directory name in the directory path information; obtaining the name and the identification of a subdirectory in at least one parent-child relationship in the metadata relationship table from the at least one parent-child relationship whose identification of a parent directory is the identification of the target parent directory.

12. A file system metadata management apparatus having a communication connection with at least two memories, the at least two memories storing a metadata relationship table and a metadata entity table, the metadata entity table storing metadata of objects in a file system, the objects being files or directories, and the metadata relationship table storing parent-child relationships between the objects in the file system; the apparatus comprising: The request obtaining module is configured to obtain a path resolution request, the path resolution request comprising path information of a target object; The object obtaining module is configured to obtain, in response to the path resolution request, an identification of the target object from a parent-child relationship corresponding to the path information in the metadata relationship table; The information reading module is configured to obtain metadata corresponding to the identification of the target object from the metadata entity table.

13. The apparatus of claim 12, wherein the metadata entity table is composed of at least two entity partition tables stored in the at least two memories, each of the at least two entity partition tables corresponding to at least one object in the file system and storing metadata of the corresponding object; The information reading module is configured to determine a target entity partition table corresponding to the identification of the target object, and read the metadata corresponding to the identification of the target object from the target entity partition table.

14. The apparatus of claim 13, wherein, The information reading module is configured to: determine an encoding value corresponding to the entity identification using a preset algorithm; and determine the entity partition table corresponding to the encoding value as the target entity partition table.

15. The apparatus of any one of claims 12-15, wherein, The metadata relationship table is composed of at least two relationship partition tables stored in the at least two memories, each of the at least two relationship partition tables corresponding to at least one directory in the file system and storing parent-child relationships between the corresponding directory and a subdirectory or a file in the directory; The object obtaining module is configured to obtain the identification of the target object from a target relationship partition table corresponding to a parent directory of the target object in the path information in the at least two relationship partition tables.

16. The apparatus of claim 15, wherein, Each parent-child relationship in each of the at least two relationship partition tables comprises an identification of a directory and a name and an identification of an object in the directory; The object obtaining module is configured to: determine the identification of the parent directory of the target object in the at least two relationship partition tables according to a preset identification of a root directory of the file system and a name of at least one directory in the path information; determine a target relationship partition table corresponding to the identification of the parent directory in the at least two relationship partition tables; and read the identification of the target object from a parent-child relationship comprising the identification of the parent directory and a name of the target object in the path information in the target relationship partition table.

17. The apparatus of claim 16, wherein, The object obtaining module is configured to: determine an encoding value corresponding to the identification of the parent directory using a preset algorithm; and determine a relationship partition table corresponding to the encoding value in the at least two relationship partition tables as the target relationship partition table.

18. An electronic device, comprising: The apparatus comprises: a processor; a memory for storing executable instructions of the processor; wherein the processor is configured to execute the instructions to implement the method of any one of claims 1 to 11.

19. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program, when executed by the processor, causes the processor to implement the method of any one of claims 1 to 11.

20. A computer program product, characterised in that, The computer program product comprises computer instructions stored in a computer readable storage medium, and a processor of a computer device reads and executes the computer instructions from the computer readable storage medium to implement the method in any one of claims 1 to 11.

Images