File metadata storage method, device and equipment

Abstract

The invention provides a file metadata storage method, device and equipment, and relates to the technical field of databases and file systems. The method comprises the steps that an index node number of a first file is generated into a combination of a resource group identifier, a metadata group identifier and a use position, a resource group comprises a first area, the first area comprises a plurality of metadata groups, each metadata group comprises a plurality of blocks, each block is used for storing metadata of a plurality of files, and each block is used for storing metadata of a plurality of files; using the position to indicate the sequence of storing the file metadata in the block, wherein N, M and X are integers greater than or equal to 2; and storing the file metadata of the first file according to the resource group, the metadata group and the use position indicated by the index node number. According to the method, the storage space requirement of the file metadata can be reduced.

Description

Technical Field

[0001] This application relates to the fields of database technology and file system technology, and in particular to a method, apparatus and device for storing file metadata. Background Technology

[0002] In modern data center and cloud storage environments, users need to efficiently manage massive amounts of files (such as millions or even billions of files and directories), while requiring file systems to have high-concurrency read and write capabilities, low-latency response, and optimized resource utilization.

[0003] In the file systems of related technologies, the file metadata of each file is usually stored in units of fixed-size blocks. As the number of files grows exponentially, this storage method leads to a serious waste of file metadata storage space. Summary of the Invention

[0004] This application provides a method, apparatus, and device for storing file metadata, thereby reducing the storage space requirements for file metadata.

[0005] In a first aspect, this application provides a method for storing file metadata, comprising: generating an inode number of a first file into a combination of a resource group identifier, a metadata group identifier, and a usage location, wherein the resource group includes a first region, and the first region includes... Each metadata group contains [number] metadata groups, and each metadata group includes [number] metadata groups. Each block is used for storage. The file metadata is stored in the block according to the position indicated by the inode number, where N, M, and X are all integers greater than or equal to 2; the file metadata of the first file is stored according to the resource group, metadata group, and position indicated by the inode number.

[0006] In one possible embodiment, after storing the file metadata of the first file, the method further includes: recording the starting address and usage location of the metadata group through directory metadata.

[0007] In one possible embodiment, after recording the starting address and usage location of a metadata group through directory metadata, the method further includes: caching metadata groups with access frequency greater than a threshold to a cache area in memory.

[0008] In one possible embodiment, before generating the inode number of the first file as a combination of the resource group identifier, metadata group identifier, and usage location, the method further includes: sequentially assigning consecutive addresses to files in the directory where the first file is located. Each block.

[0009] In one possible embodiment, the method further includes adjusting the value of M based on the number of files in the directory where the first file is located.

[0010] In one possible embodiment, N is 7, M is 3, and X is 4.

[0011] In one possible embodiment, before generating the inode number of the first file as a combination of the resource group identifier, the metadata group identifier, and the usage position, the method further includes: detecting whether the usage position of the previous file preceding the first file has reached the maximum allowed usage position in the metadata group; if not, incrementing the usage position of the previous file to obtain the usage position; if so, re-requesting the metadata group.

[0012] In one possible embodiment, the resource group includes a second region separated from the first region, the second region being used to store file data.

[0013] Secondly, this application provides a file metadata storage device, comprising: a generation module, configured to generate an inode number of a first file into a combination of a resource group identifier, a metadata group identifier, and a usage location, wherein the resource group includes a first region, and the first region includes... Each metadata group contains [number] metadata groups, and each metadata group includes [number] metadata groups. Each block is used for storage. The file metadata is stored in a block according to the position indicated by the inode number, where N, M, and X are all integers greater than or equal to 2; the storage module is used to store the file metadata of the first file according to the resource group, metadata group, and position indicated by the inode number.

[0014] Thirdly, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method as described in any of the first aspects.

[0015] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the first aspects.

[0016] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects.

[0017] In this embodiment, by refining the disk structure into partitions, dedicated storage for file metadata is achieved. Specifically, file metadata is stored only in the first region, facilitating efficient subsequent retrieval of file metadata. The first region is further subdivided into hierarchical levels, specifically, the disk is divided sequentially into resource groups, metadata groups, and blocks. Each block can store... This allows for the storage of file metadata, thereby improving the utilization of file metadata storage space and reducing I / O operations (theoretically, it can reduce the number of I / O operations to 1 / 3 of the original number). This can improve the read and write performance of files and file metadata.

[0018] The first file can be uniquely identified by generating its inode number as a combination of a resource group identifier, a metadata group identifier, and a usage location. This inode number is also associated with a storage location. Efficient storage of file metadata is achieved by storing the file metadata of the first file according to the resource group, metadata group, and usage location indicated by the inode number, thus saving storage space. Attached Figure Description

[0019] 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.

[0020] Figure 1 This is a schematic diagram illustrating the storage of file metadata for related technologies.

[0021] Figure 2 This is a schematic diagram of the disk structure of related technologies;

[0022] Figure 3 This is a schematic diagram illustrating an application scenario of the file metadata storage method according to an embodiment of this application;

[0023] Figure 4 This is a flowchart illustrating a file metadata storage method according to an embodiment of this application;

[0024] Figure 5 This is a schematic diagram of the disk structure according to an embodiment of this application;

[0025] Figure 6 This is a schematic diagram of file metadata storage according to an embodiment of this application;

[0026] Figure 7 This is a schematic diagram of a file metadata storage device according to an embodiment of this application;

[0027] Figure 8 This is a schematic diagram of an electronic device according to an embodiment of this application.

[0028] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0029] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0030] The technical terms used in the embodiments of this application will be explained below.

[0031] File system: The interface layer between the operating system and storage devices, which is a logical mechanism for organizing, storing, managing and accessing data.

[0032] Directory: Container objects in the file system.

[0033] Metadata: A collection of information describing the attributes of a file / data file. A file includes file metadata and file data.

[0034] File metadata includes at least one of the following: file creation time, modification time, access time, permissions, owner, file size, and file data storage location.

[0035] Disk: A persistent physical storage device. In this embodiment, files are stored on the disk, meaning the disk serves as the underlying storage medium for the file system.

[0036] Resource group: A logical unit for dividing disk space in a file system. A resource group divides a disk into multiple independent, resource-managed storage segments.

[0037] Inode number: A numerical identifier that uniquely identifies a file in a file system.

[0038] Block: The smallest unit of storage allocation in a file system. The size of a block is typically 4KB, 8KB, etc.

[0039] In distributed storage systems, clustered file systems are widely used in large-scale data storage scenarios. These file systems need to efficiently manage massive amounts of files and directories and support high-concurrency file access requests. In practical applications, file systems need to frequently handle file creation, deletion, searching, and traversal operations, especially for extremely large directories containing tens or even hundreds of thousands of files.

[0040] Figure 1 This is a schematic diagram illustrating the storage of file metadata for related technologies.

[0041] like Figure 1 As shown, a directory is a container object of the file system, such as a download directory or a document directory. Users can see this directory, which can take the form of a folder.

[0042] The target metadata includes mappings, which are represented by filenames and inode numbers. The inode number indicates the location on disk of the file metadata assigned by the system for each file in the directory.

[0043] like Figure 1 As shown, the inode number corresponding to filename 1 in the directory is disk address 1, meaning that the file metadata of filename 1 in the directory is stored at disk address 1.

[0044] Figure 2 This is a schematic diagram of the disk structure of related technologies.

[0045] like Figure 2 As shown, the disk comprises y resource groups, each of which includes a mixed area for storing file metadata and file data, where y is an integer greater than or equal to 2.

[0046] For example, in addition to the mixed area, the disk also includes a header and a bitmap. The header includes data such as the unique identifier of the resource group, the spatial range of the resource group, and the number of blocks within the resource group. The bitmap is used to mark the free or occupied status of each block within the resource group.

[0047] The mixed area is used to store file metadata and file data in a mixed manner. That is, file metadata and file data are not partitioned in the mixed area, but are randomly distributed in the resource group.

[0048] On the one hand, file metadata is stored in blocks, each 4KB in size. However, the file metadata itself only requires about 256 bytes, resulting in a storage space utilization rate of only about 6% for file metadata, with the remaining storage space becoming unusable. Understandably, in scenarios with extremely large directories, storage overhead increases exponentially.

[0049] On the other hand, the inode number directly maps to the disk address, and file metadata is scattered across the disk. When performing directory traversal operations such as viewing file details (list-long listing format, ls) or calculating directory size (disk usage, du), the discontinuous nature of the file metadata on the disk leads to low performance for these traversal operations.

[0050] On the other hand, directory metadata, including mapping relationships, also needs to be stored on disk. Each block can store hundreds of mapping relationships, and in the case of extremely large directories (such as a single directory with thousands or tens of thousands of files), a significant number of additional blocks are needed to store the directory metadata.

[0051] Therefore, the related technologies have problems such as wasted file metadata storage space, frequent reading of scattered disk addresses for file metadata traversal operations, significantly increasing I / O counts and latency, making it difficult to meet the requirements of high concurrency and low latency file metadata storage.

[0052] Based on this, embodiments of this application provide a method, apparatus, and device for storing file metadata. By reconstructing the storage structure and allocation mechanism of file metadata in the file system, efficient storage and fast access to file metadata are achieved. Specifically, the storage space for file metadata is changed from discrete allocation to contiguous allocation. Simultaneously, a computable inode number generation rule independent of disk addresses is designed, achieving a dual improvement in storage efficiency and access performance.

[0053] Figure 3 This is a schematic diagram illustrating an application scenario of the file metadata storage method according to an embodiment of this application.

[0054] like Figure 3 As shown, user 1 initiates a request through application 3 installed on terminal device 2 to request the creation or access of a file. This request is sent to electronic device 4. Electronic device 4 can be a server, or a node in a distributed cluster, on which a distributed file system is deployed. Electronic device 4 executes the file metadata storage method of this embodiment according to the request to store the file metadata.

[0055] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0056] Figure 4This is a flowchart illustrating a file metadata storage method according to an embodiment of this application. The file metadata storage method of this embodiment can be executed by an electronic device, which can be a server.

[0057] like Figure 4 As shown, the file metadata storage method of this application embodiment includes steps S110 to S120.

[0058] S110. Generate the inode number of the first file as a combination of resource group identifier, metadata group identifier and usage location.

[0059] The resource group includes the first region, and the first region includes... Each metadata group contains [number] metadata groups, and each metadata group includes [number] metadata groups. Each block is used for storage. Each file contains metadata, with position indicating the order in which the file metadata is stored in the block. N, M, and X are all integers greater than or equal to 2.

[0060] The location can be understood as the specific location within a metadata group where file metadata is stored. A metadata group includes... Each block stores [number of blocks]. In the case of file metadata, the usage location can be from 1 to The numerical representation of .

[0061] In one possible embodiment, generating the inode number of the first file as a combination of the resource group identifier, the metadata group identifier, and the usage location includes concatenating the resource group identifier, the metadata group identifier, and the usage location to form the inode number of the first file. For example, if the resource group identifier is 2004, the metadata group identifier is 108, and the usage location is 18, then the corresponding inode number is 2004108018.

[0062] S120. Store the file metadata of the first file according to the resource group, metadata group and usage location indicated by the inode number.

[0063] For example, the server may respond to a request to create a first file by performing step S110, where the first file is any file.

[0064] To provide a detailed and intuitive explanation of the file metadata storage method in this application, the following explanation will use N=7, M=3, and X=4 as an example. Figure 5 This is a schematic diagram of the disk structure according to an embodiment of this application.

[0065] like Figure 5 As shown, the disk comprises multiple resource groups. Each resource group, in addition to the header and bitmap, includes a first area for storing file metadata. Figure 5In the example, the first region includes 128 metadata groups, each metadata group includes 8 blocks, and each block can store file metadata corresponding to 16 inode numbers.

[0066] In this embodiment, by refining the disk structure into partitions, dedicated storage for file metadata is achieved. Specifically, file metadata is stored only in the first region, facilitating efficient subsequent retrieval of file metadata. The first region is further subdivided into hierarchical levels, specifically, the disk is divided sequentially into resource groups, metadata groups, and blocks. Each block can store... This allows for the storage of file metadata, thereby improving the utilization of file metadata storage space and reducing I / O operations (theoretically, it can reduce the number of I / O operations to 1 / 3 of the original number). This can improve the read and write performance of files and file metadata.

[0067] The first file can be uniquely identified by generating its inode number as a combination of a resource group identifier, a metadata group identifier, and a usage location. This inode number is also associated with a storage location. Efficient storage of file metadata is achieved by storing the file metadata of the first file according to the resource group, metadata group, and usage location indicated by the inode number, thus saving storage space.

[0068] like Figure 5 As shown, in one possible embodiment, the resource group includes a second region separated from the first region. The second region is used to store file data. "Separated" can be understood as the file metadata of the first region and the file data of the second region not being stored together. For example, in... Figure 5 In the example, the electronic device reserves 1024 blocks as the first region, and the remaining blocks in resource group 1 are the second region.

[0069] In this embodiment, dividing the storage space of a resource group into a first region and a second region according to file metadata and file data provides a foundation for ensuring the continuity of both file metadata and file data. Subsequent I / O operations on file metadata or file data exhibit better performance.

[0070] like Figure 2 As shown, in one possible embodiment, after step S120, the file metadata storage method further includes step S130.

[0071] S130. Record the starting address and usage location of the metadata group through the directory metadata record.

[0072] The starting address of the metadata group refers to the metadata group's address. The physical address of the first block in the sequence of blocks.

[0073] In this embodiment, since the inode number of each file can represent the storage location of the file metadata for that file, the directory metadata does not need to represent the storage location of the file metadata for each file in that directory. In contrast, in related technologies, directory metadata requires... With this mapping relationship, this embodiment of the application only requires one record of the starting address and usage location of the metadata group to fully describe the directory. The storage space for the corresponding directory metadata can be saved by 1 / .

[0074] Figure 6 This is a schematic diagram of file metadata storage according to an embodiment of this application.

[0075] like Figure 6 As shown, the starting address of metadata group 1 in the directory metadata record is disk address 1, which is also the address of block 1, and the starting address of metadata group 2 is disk address 2. Taking metadata group 1 as an example, this metadata group includes blocks 1 to 8, and block 1 can store the file metadata of 16 files.

[0076] In one possible embodiment, after step S130, the file metadata storage method further includes: caching metadata groups with access frequency greater than a threshold to a cache area in memory.

[0077] For example, the threshold can be set to one of the following: 5 times / 5 minutes, 10 times / 5 minutes, or 20 times / 5 minutes. Of course, the specific threshold setting can be selected according to the actual scenario.

[0078] For example, a cache region can cache metadata groups that are accessed more frequently than a threshold using the Least Recently Used (LRU) algorithm.

[0079] In this embodiment, by caching metadata groups with access frequencies exceeding a threshold to a cache area in memory, the number of disk I / O accesses can be reduced through a caching strategy. For example, during directory traversal operations, the electronic device can directly obtain the starting address and usage location of the metadata group from the cache area, instead of reading the disk multiple times. This improves the response speed of file access and reduces disk load.

[0080] In one possible embodiment, prior to step S110, the file metadata storage method further includes: assigning consecutive addresses to files in the directory containing the first file. Each block.

[0081] In this embodiment of the application, consecutive addresses are allocated sequentially to files in the directory where the first file is located. This allows for a block allocation strategy that utilizes contiguous addresses. This improves storage space allocation efficiency, directory traversal efficiency, and directory read / write performance. For example, in this embodiment, by sequentially allocating contiguous addresses to files in the directory... The block allocation strategy for contiguous addresses allows for the traversal of contiguous addresses in a single operation during directory traversal. The directory corresponding to each block.

[0082] In one possible embodiment, the file metadata storage method further includes adjusting the value of M according to the number of files in the directory where the first file is located.

[0083] In this embodiment, by adjusting the value of M according to the number of files in the directory where the first file is located, the number of physical storage units (blocks) of the disk can be dynamically adjusted to adapt to directories with different numbers of files and their corresponding file metadata storage needs. For example, in highly dynamic scenarios (such as frequent file creation / deletion), this embodiment can avoid the problem of redundant reserved space or insufficient capacity caused by a fixed-size metadata group, extend the life cycle of the resource group, and optimize storage continuity.

[0084] In this embodiment of the application, for any directory, firstly, allocation is performed. Each block is used to store the file metadata of the files in this directory, which is the default number of files in each directory. This should meet your needs. Of course, if the number of files in this directory is large, If the requirements are not met, a new metadata group can be requested. Furthermore, if all resources are exhausted... If you already have a metadata group, you can apply for a new resource group.

[0085] In one possible embodiment, before step S110, the file metadata storage method further includes: detecting whether the usage position of the previous file before the first file has reached the maximum usage position allowed in the metadata group; if not, incrementing the usage position of the previous file to obtain the usage position; if so, re-applying for a metadata group.

[0086] For example, the maximum number of usage locations allowed for metadata group 1 are... The position L of the previous file preceding the first file is less than the position corresponding to metadata group 1. In this case, the usage position of the file metadata of the first file can be incremented by one based on the usage position of the file preceding the first file to obtain the usage position L+1 of the file metadata of the first file. The usage position L of the file preceding the first file is equal to... In such cases, a new metadata group can be requested from the resource group, for example, the new metadata group would be metadata group 2. It is understood that the file metadata of the first file corresponds to the first usage position of the first block in the new metadata group.

[0087] The file metadata storage space utilization rate of this application embodiment is higher. Therefore, for the same size storage space per metadata group, this application embodiment can store file metadata for more files. By detecting whether the usage position of the file preceding the first file reaches the maximum allowed usage position in the metadata group, the storage space of the current directory can be determined (by default, the directory where the first file is located is allocated first). If there is enough space in the block to store the file metadata of the first file, then the usage position is incremented based on the usage position of the previous file to record the storage location of the new, consecutive file metadata. If there is not enough space in the block to store the file metadata of the first file, then a new metadata group is requested to dynamically match the storage location recording with the number of files in the directory where the first file is located.

[0088] Each metadata group corresponds to a larger amount of file metadata, which reduces the frequency with which electronic devices request new metadata groups from resource groups, thus reducing competition for resource groups.

[0089] In summary, the file metadata storage method according to the embodiments of this application has at least one of the following technical effects:

[0090] 1. By generating the inode number of the first file as a combination of resource group identifier, metadata group identifier, and usage location, the storage location of the corresponding file's metadata can be directly represented using the inode. Compared to recording mapping relationships in directory metadata, recording the starting address and usage location of metadata groups in directory metadata can reduce the storage space required for storing directory metadata.

[0091] 2. Stored by each block Individual file metadata can reduce the storage space of file metadata and improve the I / O performance of file metadata.

[0092] 3. By generating the inode number of the first file as a combination of resource group identifier, metadata group identifier, and usage location, the storage location of the file metadata of the corresponding file can be directly represented by the inode, thus creating a directory.

[0093] 4. Each metadata group corresponds to a larger amount of file metadata, which reduces the frequency with which electronic devices request new metadata groups from resource groups, thus reducing competition for resource groups.

[0094] 5. By checking if the position of the file preceding the first file reaches the maximum allowed position in the metadata group; if not, the position of the preceding file is incremented to obtain the new position, ensuring that the file metadata is stored contiguously. This is crucial for allocating contiguous addresses to files in the directory. Based on individual blocks, the physical block order of file metadata for multiple files on the disk and the logical order within each block can be continuous, improving I / O performance.

[0095] 6. By using the partition values ​​of the first and second regions in the resource group, file metadata and file data can be stored separately in the resource group to improve I / O performance.

[0096] Figure 7 This is a schematic diagram of the structure of a file metadata storage device according to an embodiment of this application. Figure 7 As shown, the file metadata storage device provided in this application embodiment includes a generation module 210 and a storage module 220.

[0097] Generation module 210 is used to generate the inode number of the first file into a combination of resource group identifier, metadata group identifier, and usage location. The resource group includes a first region, and the first region includes... Each metadata group contains [number] metadata groups, and each metadata group includes [number] metadata groups. Each block is used for storage. Each file contains metadata, with position indicating the order in which the file metadata is stored in the block. N, M, and X are all integers greater than or equal to 2.

[0098] Storage module 220 is used to store the file metadata of the first file according to the resource group, metadata group and usage location indicated by the inode number.

[0099] In one possible embodiment, the device further includes a recording module for recording the starting address and usage location of a metadata group through directory metadata.

[0100] In one possible embodiment, the device further includes a caching module for caching metadata groups accessed more frequently than a threshold to a cache region in memory.

[0101] In one possible embodiment, the apparatus further includes: an allocation module, configured to sequentially allocate consecutive addresses to files in the directory containing the first file. Each block.

[0102] In one possible embodiment, the device further includes an adjustment module for adjusting the value of M based on the number of files in the directory where the first file is located.

[0103] In one possible embodiment, N is 7, M is 3, and X is 4.

[0104] In one possible embodiment, the device further includes: a detection module for detecting whether the usage position of the previous file preceding the first file has reached the maximum allowed usage position in the metadata group; an increment processing module for incrementing the usage position of the previous file to obtain the usage position if not; and an application module for reapplying for the metadata group if yes.

[0105] In one possible embodiment, the resource group includes a second region separated from the first region, the second region being used to store file data.

[0106] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8 As shown, this application embodiment provides an electronic device including a processor 301 and a memory 302. Optionally, the device further includes a communication component 303. The processor 301, memory 302, and communication component 303 are connected via a bus 304.

[0107] In the specific implementation process, the memory 302 stores code, and the processor 301 runs the code stored in the memory 302 to execute the method of the above method embodiment.

[0108] The specific implementation process of processor 301 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0109] In the above Figure 8 In the illustrated embodiments, it should be understood that the processor 301 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0110] The memory 302 may include high-speed RAM memory, and may also include non-volatile memory (NVM), such as at least one disk storage.

[0111] Bus 304 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Bus 304 can be divided into address bus, data bus, control bus, etc. For ease of illustration, the bus 304 in the accompanying drawings of this application is not limited to only one bus or one type of bus.

[0112] This application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods described in the above-described method embodiments.

[0113] The aforementioned computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0114] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0115] This application provides a computer program product, including a computer program that, when executed by a processor, implements the methods provided in any of the embodiments described above.

[0116] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0117] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0118] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0119] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0120] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0121] If the integrated unit / module is implemented as a software program module and sold or used as an independent financial product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software financial product. This computer software financial product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0122] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0123] 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. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0124] 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 method for storing file metadata, characterized in that, include: The inode number of the first file is generated as a combination of a resource group identifier, a metadata group identifier, and a usage location. The resource group includes a first region, which includes... Each metadata group contains [number] metadata groups, and each metadata group includes [number] metadata groups. Each block is used for storage. File metadata, wherein the location indicates the order in which the file metadata is stored in the block, and N, M, and X are all integers greater than or equal to 2; The file metadata of the first file is stored according to the resource group, metadata group, and usage location indicated by the inode number.

2. The method according to claim 1, characterized in that, After storing the file metadata of the first file, the method further includes: The directory metadata records the starting address of the metadata group and its usage location.

3. The method according to claim 2, characterized in that, After recording the starting address and usage location of the metadata group through directory metadata, the method further includes: Metadata groups accessed more frequently than a threshold are cached in a cache area in memory.

4. The method according to claim 1, characterized in that, Before generating the inode number of the first file as a combination of resource group identifier, metadata group identifier, and usage location, the method further includes: For the directory where the first file is located, sequentially allocate consecutive addresses to the files in the directory. Each block.

5. The method according to claim 4, characterized in that, The method further includes: Adjust the value of M based on the number of files in the directory where the first file is located.

6. The method according to any one of claims 1-4, characterized in that, N is 7, M is 3, and X is 4.

7. The method according to claim 4, characterized in that, Before generating the inode number of the first file as a combination of resource group identifier, metadata group identifier, and usage location, the method further includes: Detect whether the usage position of the previous file preceding the first file reaches the maximum allowed usage position in the metadata group; If not, the usage position of the previous file is incremented to obtain the usage position; If so, then re-request the metadata group.

8. The method according to any one of claims 1-4, characterized in that, The resource group includes a second region separated from the first region, the second region being used to store file data.

9. A file metadata storage device, characterized in that, include: The generation module is used to generate a combination of a resource group identifier, a metadata group identifier, and a usage location from the inode number of the first file. The resource group includes a first region, which includes... Each metadata group contains [number] metadata groups, and each metadata group includes [number] metadata groups. Each block is used for storage. File metadata, wherein the location indicates the order in which the file metadata is stored in the block, and N, M, and X are all integers greater than or equal to 2; The storage module is used to store the file metadata of the first file according to the resource group, metadata group and usage location indicated by the inode number.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 8.

Images