Method for managing local file system, electronic device and readable storage medium

Abstract

The application discloses a local file system management method, electronic equipment and a readable storage medium, relates to the technical field of file management, each object in the local file system comprises a plurality of file storage areas storing index node data, target file metadata of a target file is stored in a file storage area corresponding to idle index node data obtained based on an idle index node queue, and a target directory entry is constructed according to a target file name, a target file type and a target index node number; a target object corresponding to the target file name is determined based on a linear hash function; if the target file name cannot be found in the target object based on a multi-path cuckoo hash function, and no directory entry slot in an idle state exists in the target object, the target object is split based on the linear hash function to create an idle directory entry slot required to be inserted in the target object. The application solves the problem of poor expansion convenience of the local file system in the cloud storage environment.

Description

Technical Field

[0001] This application relates to the field of file management technology, and in particular to a method for managing a local file system, an electronic device, and a readable storage medium. Background Technology

[0002] With the rapid development of cloud computing technology, we have now entered the cloud-native era. Cloud-native technologies, with their elastic scaling, automatic deployment, and fault self-healing features, are attracting more and more applications to adopt them. However, the underlying storage in cloud-native environments is mainly based on distributed object storage systems. Object storage can only provide simple key-value data management interfaces and cannot effectively meet the data processing requirements of many industry applications. Therefore, many applications still require the support of local file system interfaces.

[0003] Currently, when using a local file system in a cloud-native environment, it is usually done by adding a virtual block device to the local file system so that the local file system can use the virtual block device for quick formatting and mounting. However, the virtual block device has a fixed capacity during initialization, and subsequent expansion requires re-initializing the virtual device and restoring the original content stored on the virtual block device. Therefore, the existing local file system in the cloud storage environment has poor expansion convenience. Summary of the Invention

[0004] The main purpose of this application is to provide a method, apparatus, electronic device and readable storage medium for managing a local file system, aiming to solve the technical problem of poor ease of expansion of existing local file systems in cloud storage environments.

[0005] To achieve the above objectives, this application provides a method for managing a local file system, wherein each object in the local file system includes multiple file storage areas storing inode data, and the method for managing the local file system includes:

[0006] Obtain the target file metadata of the target file, and extract the target file name and target file type from the target file metadata;

[0007] Based on the idle index node queue, obtain the idle index node data and the target index node number corresponding to the idle index node data;

[0008] The target file metadata is stored in the file storage area corresponding to the free inode data, and a target directory entry is constructed based on the target file name, the target file type, and the target inode number;

[0009] The target object corresponding to the target file name is determined based on a linear hash function;

[0010] If the target file name cannot be found in the target object based on the multi-way cuckoo hash function, and there are no free directory entry slots in the target object, then the target object is split based on the linear hash function to create free directory entry slots.

[0011] Insert the target directory entry into the free directory entry slot to complete the creation of the target file.

[0012] Optionally, the step of determining the target object corresponding to the target filename based on a linear hash function includes:

[0013] The linear hash function is initialized based on the linear hash variable in the parent directory to calculate the bucket number where the target file name is located;

[0014] By combining the inode number of the parent directory and the bucket number, the target object number is obtained;

[0015] Using the target object number as an index, search for the target object corresponding to the target object number in the local file system.

[0016] Optionally, after the step of combining the inode number of the parent directory and the bucket number to obtain the target object number, the local file system management method further includes:

[0017] If the target object corresponding to the target object number cannot be found in the local file system using the target object number as an index, then a free object in the local file system is used as the target object and associated with the target object number. Here, the free object refers to an object that has no associated object number.

[0018] Optionally, the step of obtaining idle inode data and the target inode number corresponding to the idle inode data based on the idle inode queue includes:

[0019] If there is idle index node data in the idle index node queue, then the index node number corresponding to the first index node data pointed to by the head pointer in the idle index node queue is taken as the target index node number, and the index node data corresponding to the target index node number is taken as the idle index node data.

[0020] If there are no idle index node data in the idle index node queue, a new object is created to store the index node numbers corresponding to the multiple index node data contained in the new object into the idle index node queue, thereby obtaining the target idle index node queue.

[0021] In the target free index node queue, the index node number corresponding to the first index node data pointed to by the head pointer is taken as the target index node number, and the index node data corresponding to the target index node number is taken as the free index node data;

[0022] The step of splitting the target object based on a linear hash function to create free directory entry slots includes:

[0023] The target object is split based on the round-robin scheduling algorithm in the linear hash function to create free directory entry slots.

[0024] Optionally, the step of inserting the target directory entry into the free directory entry slot includes:

[0025] Obtain the remaining directory entries in the target directory, excluding the target file name;

[0026] The remaining directory entries are stored from the head of the free directory entry slot, and the target file name is stored from the tail of the free directory entry slot.

[0027] Optionally, after the step of inserting the target directory entry into the free directory entry slot, the local file system management method further includes:

[0028] In response to a file data read instruction for the target file, the target inode number in the target directory entry is extracted, and the data size and file offset of the file data to be read are obtained;

[0029] Calculate the logical block number of the file data to be read based on the data size and the file offset;

[0030] The global object number is obtained by combining the target inode number and the logical block number;

[0031] Read the file data to be read from the target file from the storage area corresponding to the global object number.

[0032] Optionally, after the step of inserting the target directory entry into the free directory entry slot, the local file system management method further includes:

[0033] In response to a file information read instruction for the target file, extract the target inode number from the target directory entry;

[0034] The file information of the target file is read by reading the inode data corresponding to the target inode number.

[0035] Optionally, after the step of inserting the target directory entry into the free directory entry slot, the local file system management method further includes:

[0036] In response to a file deletion command on the target file, extract the target inode number from the target directory entry;

[0037] Delete the target file and the target inode number from the file storage area corresponding to the target inode number;

[0038] The target inode number is inserted into the object storage area pointed to by the tail pointer in the idle inode queue.

[0039] This application also provides a management device for a local file system, wherein each object in the local file system includes multiple file storage areas storing inode data, and the management device for the local file system includes:

[0040] The first acquisition module is used to acquire the target file metadata of the target file and extract the target file name and target file type from the target file metadata;

[0041] The second acquisition module is used to acquire idle index node data and the target index node number corresponding to the idle index node data based on the idle index node queue.

[0042] The storage module is used to store the target file metadata in the file storage area corresponding to the free inode data, and to construct the target directory entry based on the target file name, the target file type and the target inode number;

[0043] The determination module is used to determine the target object corresponding to the target file name based on a linear hash function.

[0044] A module is created to split the target object based on a linear hash function to create free directory entry slots if the target file name cannot be found in the target object based on a multi-way cuckoo hash function and there are no free directory entry slots in the target object.

[0045] An insertion module is used to insert the target directory entry into the free directory entry slot to complete the creation of the target file.

[0046] This application also provides an electronic device, which is a physical device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to perform the steps of the local file system management method as described above.

[0047] This application also provides a readable storage medium, which is a computer-readable storage medium, on which a program implementing a local file system management method is stored. The program implementing the local file system management method is executed by a processor to implement the steps of the local file system management method as described above.

[0048] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the local file system management method described above.

[0049] This application provides a method for managing a local file system. Each object in the local file system includes multiple file storage areas storing inode data. First, the application obtains the target file metadata of the target file and extracts the target file name and target file type from the target file metadata. Then, it obtains the idle inode data and the target inode number corresponding to the idle inode data based on the idle inode queue. Next, it stores the target file metadata in the file storage area corresponding to the idle inode data and constructs a target directory entry based on the target file name, target file type, and target inode number. Then, it determines the target object corresponding to the target file name based on a linear hash function. If the target file name cannot be found in the target object using a multi-way cuckoo hash function, and there are no idle directory entry slots in the target object, it indicates that the target file name is not stored in the target object of the local file system, and all directory entry slots of the target object are used. In this case, the target object is split using a linear hash function to create idle directory entry slots. Finally, the target directory entry is inserted into the idle directory entry slot, thus completing the creation of the target file in the local file system. Therefore, this application implements the file storage process through objects in the local file system, overcoming the technical shortcomings of existing file storage processes that require the addition of virtual block devices, reducing the usage cost of the local file system. Furthermore, this application uses linear hash functions and multi-way cuckoo functions to quickly locate directory entry slots and create free directory entry slots in the local file system, thereby achieving dynamic scaling of the local file system's storage space. This solves the technical problem of poor convenience of local expansion in cloud storage environments and improves the convenience of expansion. Attached Figure Description

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

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

[0052] Figure 1 This is a structural diagram provided for Embodiment 1 of the document management system of this application;

[0053] Figure 2 A flowchart illustrating the method for managing the local file system in this application (Example 1).

[0054] Figure 3 This is a schematic diagram of managing index node data based on a circular queue, provided in Embodiment 1 of this application.

[0055] Figure 4 A simplified flowchart illustrating the file creation operation in the local file system management method provided in Embodiment 1 of this application;

[0056] Figure 5 A flowchart illustrating the second embodiment of the local file system management method of this application;

[0057] Figure 6 A schematic diagram of the storage structure of directory entries and file names provided in Embodiment 2 of this application;

[0058] Figure 7 A simplified flowchart illustrating the file data reading operation in the local file system management method provided in Embodiment 2 of this application;

[0059] Figure 8 A simplified flowchart illustrating the file information reading operation in the local file system management method provided in Embodiment 2 of this application;

[0060] Figure 9 This is a schematic diagram of the module structure of the local file system management device according to an embodiment of this application;

[0061] Figure 10 This is a schematic diagram of the device structure of the hardware operating environment involved in the local file system management method in this application embodiment.

[0062] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0063] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0064] Example 1

[0065] With the rapid development of cloud computing technology, we have now entered the cloud-native era. Cloud-native technologies, with their elastic scaling, automatic deployment, and fault self-healing features, are attracting more and more applications to adopt them. However, the underlying storage in cloud-native environments is mainly based on distributed object storage systems. Object storage can only provide simple key-value data management interfaces and cannot effectively meet the data processing requirements of many industry applications. Therefore, many applications still require the support of local file system interfaces.

[0066] Currently, when using a local file system in a cloud-native environment, it is usually done by adding a virtual block device to the local file system so that the local file system can use the virtual block device for quick formatting and mounting. However, the virtual block device has a fixed capacity during initialization, and subsequent expansion requires re-initializing the virtual device and restoring the original content stored on the virtual block device. Therefore, the existing local file system in the cloud storage environment has poor expansion convenience.

[0067] Alternatively, the method using the object storage block storage interface can also quickly access the local file system. However, this method requires adding a block storage layer between the object storage and the local file system. The existence of the block storage layer will prevent the storage advantages of the underlying objects from being fully utilized, which to some extent reduces the performance of the local file system.

[0068] As an example, please refer to Figure 1 , Figure 1A file management system is provided as an application of a local file system management method. This system includes a namespace management module 100 based on linear hashing and cuckoo hashing, a dynamic inode management module 200 based on a circular queue, and a computationally efficient data address space management module 300. The namespace management module 100, based on linear hashing and cuckoo hashing, organizes directory entries, retrieves the directory entry of a file by its filename, and then reads the corresponding directory entry slot. Specifically, it first calculates the object number of the filename using a linear hash function, and then searches for the directory entry slot corresponding to the filename within the object corresponding to the object number using cuckoo hashing. The dynamic inode management module 200, based on a circular queue, dynamically manages the inode data of each object. The computationally efficient data address space management module 300 calculates and constructs object numbers and uses the object storage interface to read and write the data of the corresponding object to complete data read and write operations, realizing the conversion from file data space to storage space. This example does not specifically limit the structure of the file management system.

[0069] Based on this, this application proposes a local file system management method according to a first embodiment. Each object in the local file system includes multiple file storage areas that store inode data. Please refer to... Figure 2 The management method for the local file system includes:

[0070] Step S10: Obtain the target file metadata of the target file, and extract the target file name and target file type from the target file metadata;

[0071] It should be noted that a target file refers to a file on the local file system that is currently being read, written, or created. The target file metadata consists of data representing the file and information representing its attributes. This metadata may include the target file name, target file type, target file size, and target file attributes. The target file name is the filename of the target file. The target file metadata can be obtained in real time.

[0072] It is understandable that an object includes multiple file storage areas that store inode data. That is, the total storage area corresponding to an object is divided into multiple file storage areas, and inode data is stored in each file storage area to distinguish the file storage areas in the object through the inode data.

[0073] Step S20: Obtain the idle index node data and the target index node number corresponding to the idle index node data based on the idle index node queue;

[0074] It should be noted that the idle inode queue records multiple inode data corresponding to different objects. The idle inode data refers to the inode data that is in an idle state in the idle inode queue, that is, the file storage area corresponding to the inode data is not occupied.

[0075] Further, the step of obtaining idle inode data and the target inode number corresponding to the idle inode data based on the idle inode queue includes:

[0076] Step S21: If there is idle index node data in the idle index node queue, then the index node number corresponding to the first index node data pointed to by the head pointer in the idle index node queue is taken as the target index node number, and the index node data corresponding to the target index node number is taken as the idle index node data.

[0077] It should be noted that the head pointer is used to point to the index node number corresponding to the first free index node data in the queue.

[0078] Step S22: If there is no idle index node data in the idle index node queue, a new object is created to store the index node numbers corresponding to the multiple index node data contained in the new object into the idle index node queue, thereby obtaining the target idle index node queue.

[0079] It is understandable that if there are no idle inode data in the idle inode queue, it means that the file storage area corresponding to all the inode data in the idle inode queue has been fully occupied. In this case, the storage space can be expanded by creating a new object, and the inode numbers corresponding to the multiple inode data of the new object can be stored in the idle inode queue to complete the expansion of the idle inode queue and obtain the target idle inode queue.

[0080] Step S23: In the target idle index node queue, the index node number corresponding to the first index node data pointed to by the head pointer is taken as the target index node number, and the index node data corresponding to the target index node number is taken as the idle index node data.

[0081] Step S30: Store the target file metadata in the file storage area corresponding to the free inode data, and construct the target directory entry based on the target file name, the target file type and the target inode number;

[0082] It should be noted that the target directory entry consists of the target file name, the target file type, and the target inode number.

[0083] Step S40: Determine the target object corresponding to the target file name based on a linear hash function;

[0084] It should be noted that the target object refers to the object containing the directory entry corresponding to the target file name. The local file system includes multiple objects, and each object stores multiple directory entries.

[0085] Additionally, it should be noted that this linear hash function works by using a bucket, i.e., an object, during initialization, where l = 0, next = 0, and so on. l For the number of buckets in this round, `next` points to the bucket number to be split next. During the continuous insertion of directory entries, `h` is first calculated based on `filename` (filename). l (filenama) retrieves the bucket number. If there's an empty space in the bucket, the entry is inserted directly. If the bucket is full, the overflow bucket is used to insert the directory entry into the overflow bucket. During this continuous insertion process, if the bucket reaches the splitting threshold, the bucket corresponding to next will be split. During the splitting process, the filename of each directory entry in the bucket is traversed, and h is used to... l+1 Recalculate the bucket number and move the directory entries to the split buckets. After the split is complete, increment next by 1. If next = 2 at this point... l If the result is 0, it indicates that one round of splitting has been completed. At this point, `l` is incremented by 1, `next` is set to 0, and a new round of splitting begins. During directory indexing, a hash value is calculated using the filename to be indexed. If `h`... l If (filenama) < next, it means that the bucket currently calculated by filename has been split, therefore the bucket containing the indexed filename is h. l+1 (filenama); and if h l If (filenama) ≥ next, it means that the bucket currently calculated by filename has not yet split, therefore the bucket containing the indexed filename is h. l (filenama). Specifically, the linear hash function is as follows:

[0086] h l (filename) = H(filename)%2 l

[0087]

[0088] Among them, 2 lFor the number of buckets in this round, `next` points to the bucket number to be split next, `filename` represents the filename to be indexed, `bn` represents the bucket number of the filename to be indexed, and `h`... l (filenama) and h l+1 (filenama) are all bucket numbers calculated based on the filename.

[0089] Step S50: If the target file name cannot be found in the target object based on the multi-way cuckoo hash function, and there is no idle directory entry slot in the target object, then the target object is split based on the linear hash function to create an idle directory entry slot.

[0090] It should be noted that an idle directory item slot means that the directory item slot is not occupied by the target item. The status of the directory item slot can be divided into occupied and idle states based on whether the target item slot is occupied. An idle directory item slot is a directory item slot that is in an idle state.

[0091] Additionally, it should be noted that the Cuckoo Hash Function works by using at least two hash functions for hash mapping. Taking the use of two hash functions as an example, during the continuous insertion of directory entries, the first hash function is used to perform a hash calculation based on the filename, resulting in H. l The process involves using `(filenama)` to locate a directory entry. If the located position is empty (corresponding to an idle directory entry slot mentioned above), the directory entry is inserted into that position. If the located position is not empty, a second hash function is used to calculate the hash based on the filename, resulting in `H2(filenama)`. If the located position is empty, the directory entry is inserted into that position. If the located position is not empty, the existing directory entry at that position is removed, and the new directory entry is inserted. The removed directory entry is then recalculated using the second hash function to determine its new insertion position. This process is repeated until all directory entries are successfully inserted. If, after a certain number of iterations, a directory entry is still not successfully inserted, it indicates that the object's usage rate is high, which is considered an object overflow. In this case, a linear hash function is used to handle the overflowing object. In actual use of Cuckoo Hash for directory entry lookup, to increase the fault tolerance of hash collisions and reduce the removal of directory entries, a four-way Cuckoo Hash can be used for location without placing a large amount of computational pressure on the local file system, thereby improving the efficiency of directory entry insertion.

[0092] Furthermore, the step of splitting the target object based on a linear hash function to create free directory entry slots includes:

[0093] Step S51: Split the target object based on the round-robin scheduling algorithm in the linear hash function to create free directory entry slots.

[0094] Step S60: Insert the target directory entry into the free directory entry slot to complete the creation of the target file.

[0095] This application provides a method for managing a local file system. Each object in the local file system includes multiple file storage areas storing inode data. This application first obtains the target file metadata of the target file and extracts the target file name and target file type from the target file metadata. Then, it obtains the idle inode data and the target inode number corresponding to the idle inode data based on the idle inode queue. Next, it stores the target file metadata in the file storage area corresponding to the idle inode data and constructs a target directory entry based on the target file name, target file type, and target inode number. Then, it determines the target object corresponding to the target file name based on a linear hash function. If the target file name cannot be found in the target object based on a multi-way cuckoo hash function, and there are no idle directory entry slots in the target object, it indicates that the target file name is not stored in the target object of the local file system, and all directory entry slots of the target object are used. Therefore, the target object is split based on a linear hash function to create idle directory entry slots. Finally, the target directory entry is inserted into the directory entry slot, thus completing the creation of the target file in the local file system. Therefore, this application embodiment achieves file storage through objects in the local file system, overcoming the technical shortcomings of existing file storage methods that require adding virtual block devices. This not only reduces the usage cost of the local file system but also avoids the problem of not being able to fully utilize the storage advantages of the underlying objects due to the addition of a block storage layer between object storage and the local file system, thus improving the performance of the local file system. Furthermore, by managing index node data through an idle index node queue, if there is no idle index node data in the idle index node queue, a new object can be created, that is, a new storage space can be allocated in the local file system, and the multiple index node data corresponding to the new object can be stored in the idle index node queue to expand the idle index node queue. At the same time, linear hash functions and multi-way cuckoo functions are used to quickly locate directory entry slots and create idle directory entry slots in the local file system, thereby achieving dynamic scaling of the local file system's storage space. This solves the technical problem of poor local expansion convenience in the existing cloud storage environment and improves expansion convenience.

[0096] In one possible implementation, the step of determining the target object corresponding to the target filename based on a linear hash function includes:

[0097] Step S11: Initialize the linear hash function based on the linear hash variable in the parent directory to calculate the bucket number where the target file name is located;

[0098] It should be noted that the parent directory refers to the directory one level above the current directory.

[0099] Step S12: Combine the inode number of the parent directory and the bucket number to obtain the target object number;

[0100] It should be noted that the object number consists of the inode number and the bucket number. The object number is used to identify the object in which the file is located, and the inode is used to store basic information about the file and its directory. The inode number refers to the number of the inode.

[0101] Step S13: Using the target object number as an index, search for the target object corresponding to the target object number in the local file system.

[0102] In this embodiment, a linear hash function is first initialized based on the linear hash variable in the parent directory. The bucket number of the target file name is then calculated using the initialized linear hash function. This bucket number is then combined with the inode number of the parent directory to generate a unique target object number. Using this target object number as an index, the target object corresponding to the target object number can be accurately found in the local file system. Thus, this embodiment sets the object number using the bucket number and the inode number, making the object number unique and improving the accuracy of object lookup.

[0103] In one possible implementation, after the step of combining the inode number of the parent directory and the bucket number to obtain the target object number, the local file system management method further includes:

[0104] Step S14: If the target object corresponding to the target object number cannot be found in the local file system using the target object number as an index, then an idle object in the local file system is used as the target object and associated with the target object number. Here, the idle object refers to an object that has no associated object number.

[0105] It is understandable that if the target object number cannot be found in the local file system, it means that there is no related object storing the target object number in the local file system. In this case, an object in the local file system that does not have an associated object number can be used as the target object and associated with the target object number.

[0106] To aid in understanding the technical concept or principles of this application, please refer to... Figure 3 Object A stores multiple inodes. The inode number (ino) in the inode data is constructed from the object number (oid) and the offset within the object (off). The object number is a local atomic auto-incrementing integer. Since the number of inodes contained in a single object is fixed, the offset within the object can be directly used to index the inode data within the object. Therefore, the inode data can be quickly located and read based on the inode number.

[0107] Figure 3 The circular queue in the left-middle section records the inode numbers of idle inode data. This circular queue consists of multiple queues, each containing a fixed number of inode numbers, a head pointer, and a tail pointer. The head pointer points to the first idle inode in the queue, and the tail pointer points to the next empty file storage area in the queue used to store the inode number of the deleted inode data. Since each queue can only store a limited number of inode numbers, a new queue is requested for insertion when a single queue is full. Specifically, when new inode data needs to be requested, the inode number of the inode data pointed to by the head pointer is retrieved, and the head pointer is moved to the right. The local file system reads the inode data from object A based on the retrieved inode number and performs the corresponding operation to request the new inode data. When existing inode data needs to be deleted, the inode number of the deleted inode data is inserted into the file storage area pointed to by the tail pointer, and the tail pointer is moved to the right, thus realizing the deletion operation.

[0108] It should be noted that the above specific embodiments are only used to understand this application and do not constitute a limitation on the local file system management method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0109] For example, please refer to Figure 4 , Figure 4 A simplified flowchart of file creation operations in a local file system management method is provided, specifically:

[0110] 1. Receive file creation requests from upper-layer applications for target files;

[0111] 2. Calculate the bucket number bn of the target file's filename based on a linear hash function;

[0112] 3. Construct the object number based on the inode number pino and bucket number bn of the parent directory:<pino,bn> ;

[0113] 4. Based on the object number, read the object from the object storage interface to determine the target object corresponding to that object number;

[0114] 5. If no target object exists corresponding to the object number, then an object is requested (corresponding to the above associating a free object in the local file system as the target object with the target object number);

[0115] 6. Within the target object, use the Cuckoo Hash function to check if the target filename exists. If it exists, return a duplicate name error.

[0116] 7. If the target file name does not exist within the target object, then request new free inode data from the free inode queue and insert the target file into the file storage area corresponding to the free inode data;

[0117] 8. Construct a new file directory entry based on the inode number (ino) of the free inode data;

[0118] 9. Based on the cuckoo hash function's operating strategy, insert new file directory entries into the target object;

[0119] 10. If the target object overflows, the target object is split based on a linear hash function, and the directory entry is inserted to complete the file creation operation.

[0120] Example 2

[0121] Based on the first embodiment of this application, in another embodiment of this application, the same or similar content as in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 5 The step of inserting the target directory entry into the free directory entry slot includes:

[0122] Step S61: Obtain the remaining directory entries in the target directory entries after removing the target file name;

[0123] It should be noted that, in the information used to characterize file-related attributes, that is, in the file information of the file, apart from the variable-length structure of the file name, all other file information is a fixed-length structure.

[0124] Step S62: Store the remaining directory entry from the head of the free directory entry slot and store the target file name from the tail of the free directory entry slot.

[0125] Understandably, the target filename has a variable-length structure, while the remaining directory entries (excluding the target filename) have a fixed-length structure. To facilitate efficient indexing using the Cuckoo Hash Function, filenames and directory entries need to be stored separately to ensure that directory entries are fixed-length and can be placed in the hash table within the Cuckoo Hash Function. For details, please refer to... Figure 6 The remaining directory entries are stored starting from the head of the free directory entry slot, and the target file name is stored starting from the tail of the free directory entry slot, growing towards the middle. When the length of the file name exceeds the set size, it is also set as an object overflow.

[0126] In this embodiment, the remaining directory entries excluding the target filename are first obtained from the target directory entries. Then, the remaining directory entries are stored from the head of the free directory entry slot, and the target filename is stored from the tail of the free directory entry slot. The target directory entry is then inserted into the free directory entry slot. Thus, by storing fixed-length directory entries and variable-length filenames separately, this embodiment ensures that the directory entries are fixed-length and can be placed in the hash table of the Cuckoo Hash Function, thereby improving the indexing efficiency of directory entries.

[0127] In one possible implementation, after the step of inserting the target directory entry into the free directory entry slot, the local file system management method further includes:

[0128] Step A10: In response to the file data reading instruction of the target file, extract the target inode number from the target directory entry, and obtain the data size and file offset of the file data to be read;

[0129] It should be noted that file offset refers to the number of bytes a file moves forward or backward from a specified position.

[0130] Step A20: Calculate the logical block number of the file data to be read based on the data size and the file offset;

[0131] It should be noted that the logical block number refers to the data block number of the storage area in which the file data to be read is located in the file storage area corresponding to the target inode data. It can be understood that a file storage area includes multiple storage areas used to store different file data.

[0132] Step A30: Combine the target inode number and the logical block number to obtain the global object number;

[0133] It should be noted that the global object number consists of the inode number and the logical block number.

[0134] Step A40, and read the file data to be read from the storage area corresponding to the global object number in the target file.

[0135] In this embodiment, the target inode number is first extracted from the target directory entry, and the logical block number of the file data to be read is calculated based on the data size and file offset of the file data to be read. Then, the global object number is obtained by combining the target inode number and the logical block number, so as to read the file data in the target file from the storage area corresponding to the global object number. Thus, this embodiment completes the data read and write operation by constructing the global object number and using the object storage interface to read and write the corresponding data, thereby eliminating the need to add an additional indirect index structure in the local file system and improving the file data reading efficiency in the local file system.

[0136] For example, please refer to Figure 7 , Figure 7 A simplified flowchart of file data reading operations in a local file system management method is provided, specifically:

[0137] 1. Receive file data read requests from upper-layer applications for target files (the aforementioned file data read instructions);

[0138] 2. Calculate the bucket number bn of the target file's filename based on a linear hash function;

[0139] 3. Construct the object number based on the inode number pino and bucket number bn of the parent directory:<pino,bn> ;

[0140] 4. Based on the object number, read the object from the object storage interface to determine the target object corresponding to that object number;

[0141] 5. Within the target object, use the Cuckoo Hash function to search for the target directory entry based on the target file name. If the target directory entry corresponding to the target file name does not exist within the target object, it means that the target file does not exist in the target object.

[0142] 6. If a target directory entry corresponding to the target file name exists inside the target object, then the target directory entry is read to extract the target inode number ino, and the corresponding inode data is read through the target inode number ino.

[0143] 7. Based on the size of the data to be read and the file offset, calculate the logical block number ln of the file data to be read;

[0144] 8. Construct the global object number using the target inode number (ino) and logical block number (ln):<ino,ln> It reads the corresponding data from the target object and completes the data reading operation.

[0145] In one possible implementation, after the step of inserting the target directory entry into the free directory entry slot, the local file system management method further includes:

[0146] Step B10: In response to the file information reading instruction of the target file, extract the target inode number from the target directory entry;

[0147] Step B20: Read the file information of the target file by reading the inode data corresponding to the target inode number.

[0148] It should be noted that file information refers to information used to characterize file-related attributes, such as file name, file access permissions, file size, file creation time, etc., while file data refers to the data recorded in the file.

[0149] In this embodiment, when it is necessary to read the file information of the target file, the file information of the target file can be read by extracting the target inode number in the target directory entry corresponding to the target file, thereby eliminating the need to add an additional indirect index structure to the local file system and improving the efficiency of reading file information in the local file system.

[0150] For example, please refer to Figure 8 , Figure 8 A simplified flowchart of file information reading operations in a local file system management method is provided, specifically:

[0151] 1. Receive file information reading requests from upper-layer applications for target files (the aforementioned file information reading instructions);

[0152] 2. Calculate the bucket number bn of the target file's filename based on a linear hash function;

[0153] 3. Construct the object number based on the inode number (ino) and bucket number (bn) of the parent directory:<ino,bn> ;

[0154] 4. Based on the object number, read the object from the object storage interface to determine the target object corresponding to that object number;

[0155] 5. Within the target object, use the Cuckoo Hash function to search for the target directory entry based on the target file name. If the target directory entry corresponding to the target file name does not exist within the target object, it means that the target file does not exist in the target object.

[0156] 6. If a target directory entry corresponding to the target file name exists inside the target object, then the target directory entry is read to extract the target inode number ino, and the corresponding inode data is read through the target inode number ino.

[0157] 7. Read the corresponding file information from the inode data to complete the file information reading operation.

[0158] In one possible implementation, after the step of inserting the target directory entry into the free directory entry slot, the local file system management method further includes:

[0159] Step C10: In response to a file deletion instruction on the target file, extract the target inode number from the target directory entry;

[0160] Step C20: Delete the target file and the target inode number from the file storage area corresponding to the target inode number;

[0161] Step C30: Insert the target inode number into the object storage area pointed to by the tail pointer in the idle inode queue.

[0162] It should be noted that the object storage area refers to the storage area of ​​an object, that is, the storage area corresponding to an object.

[0163] In this embodiment, when a target file needs to be deleted, the target inode number in the target directory entry corresponding to the target file is first extracted. Then, the target file and the target inode number are deleted from the file storage area corresponding to the target inode number. The deleted target inode number is then inserted into the object storage area pointed to by the tail pointer in the free inode queue to release the file storage area.

[0164] Example 3

[0165] This invention also provides a management device for a local file system, wherein each object in the local file system includes multiple file storage areas storing inode data. Please refer to... Figure 9 The management device for the local file system includes:

[0166] The first acquisition module 10 is used to acquire the target file metadata of the target file and extract the target file name and target file type from the target file metadata;

[0167] The second acquisition module 20 is used to acquire idle index node data and the target index node number corresponding to the idle index node data based on the idle index node queue.

[0168] Storage module 30 is used to store the target file metadata in the file storage area corresponding to the free inode data, and to construct a target directory entry based on the target file name, the target file type and the target inode number;

[0169] Module 40 is used to determine the target object corresponding to the target file name based on a linear hash function;

[0170] Module 50 is used to split the target object based on a linear hash function to create free directory entry slots if the target file name cannot be found in the target object based on the multi-way cuckoo hash function and there are no free directory entry slots in the target object.

[0171] Insertion module 60 is used to insert the target directory entry into the free directory entry slot to complete the creation of the target file.

[0172] Optionally, the determining module 40 is further configured to:

[0173] The linear hash function is initialized based on the linear hash variable in the parent directory to calculate the bucket number where the target file name is located;

[0174] By combining the inode number of the parent directory and the bucket number, the target object number is obtained;

[0175] Using the target object number as an index, search for the target object corresponding to the target object number in the local file system.

[0176] Optionally, the determining module 40 is further configured to:

[0177] If the target object corresponding to the target object number cannot be found in the local file system using the target object number as an index, then a free object in the local file system is used as the target object and associated with the target object number. Here, the free object refers to an object that has no associated object number.

[0178] Optionally, the second acquisition module 20 is further configured to:

[0179] If there is idle index node data in the idle index node queue, then the index node number corresponding to the first index node data pointed to by the head pointer in the idle index node queue is taken as the target index node number, and the index node data corresponding to the target index node number is taken as the idle index node data.

[0180] If there are no idle index node data in the idle index node queue, a new object is created to store the index node numbers corresponding to the multiple index node data contained in the new object into the idle index node queue, thereby obtaining the target idle index node queue.

[0181] In the target free index node queue, the index node number corresponding to the first index node data pointed to by the head pointer is taken as the target index node number, and the index node data corresponding to the target index node number is taken as the free index node data;

[0182] The creation module 50 is also used for:

[0183] The target object is split based on the round-robin scheduling algorithm in the linear hash function to create free directory entry slots.

[0184] Optionally, the insertion module 60 is further configured to:

[0185] Obtain the remaining directory entries in the target directory, excluding the target file name;

[0186] The remaining directory entries are stored from the head of the free directory entry slot, and the target file name is stored from the tail of the free directory entry slot.

[0187] Optionally, the management device for the local file system further includes:

[0188] In response to a file data read instruction for the target file, the target inode number in the target directory entry is extracted, and the data size and file offset of the file data to be read are obtained;

[0189] Calculate the logical block number of the file data to be read based on the data size and the file offset;

[0190] The global object number is obtained by combining the target inode number and the logical block number;

[0191] Read the file data to be read from the target file from the storage area corresponding to the global object number.

[0192] Optionally, the management device for the local file system further includes:

[0193] In response to a file information read instruction for the target file, extract the target inode number from the target directory entry;

[0194] The file information of the target file is read by reading the inode data corresponding to the target inode number.

[0195] Optionally, the management device for the local file system further includes:

[0196] In response to a file deletion command on the target file, extract the target inode number from the target directory entry;

[0197] Delete the target file and the target inode number from the file storage area corresponding to the target inode number;

[0198] The target inode number is inserted into the object storage area pointed to by the tail pointer in the idle inode queue.

[0199] The local file system management device provided by this invention, employing the local file system management method described in the above embodiments, can solve the technical problem of poor ease of expansion of existing local file systems in cloud storage environments. Compared with the prior art, the beneficial effects of the local file system management device provided by this invention are the same as those of the local file system management method provided in the above embodiments, and other technical features in the local file system management device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0200] Example 4

[0201] This invention provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the local file system management method described in Embodiment 1 above.

[0202] The following is for reference. Figure 10 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of the present disclosure. The electronic devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 10 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0203] like Figure 10As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. While electronic devices with various systems are shown in the figures, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

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

[0205] The electronic device provided by this invention, employing the local file system management method described in the above embodiments, can solve the technical problem of poor ease of expansion of existing local file systems in cloud storage environments. Compared with the prior art, the beneficial effects of the electronic device provided by this invention are the same as those of the local file system management method provided in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0206] It should be understood that various parts of this disclosure can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics may be combined in any suitable manner in one or more embodiments or examples.

[0207] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0208] Example 5

[0209] This invention provides a computer-readable storage medium having computer-readable program instructions stored thereon, which are used to execute the local file system management method described in Embodiment 1 above.

[0210] The computer-readable storage medium provided in this embodiment of the invention may be, for example, a USB flash drive, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0211] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0212] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by an electronic device, the electronic device causes the following: to acquire target file metadata of a target file, and extract the target file name and target file type from the target file metadata; to acquire idle inode data and the target inode number corresponding to the idle inode data based on an idle inode queue; to store the target file metadata in the file storage area corresponding to the idle inode data, and to construct a target directory entry based on the target file name, the target file type, and the target inode number; to determine the target object corresponding to the target file name based on a linear hash function; if the target file name cannot be found in the target object based on a multi-way cuckoo hash function, and there is no idle directory entry slot in the target object, then the target object is split based on a linear hash function to create an idle directory entry slot; and the target directory entry is inserted into the idle directory entry slot to complete the creation of the target file.

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

[0214] 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 the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0215] The modules described in the embodiments of this disclosure can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0216] The readable storage medium provided by this invention is a computer-readable storage medium that stores computer-readable program instructions for executing the aforementioned local file system management method. This solves the technical problem of poor ease of expansion of existing local file systems in cloud storage environments. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this embodiment are the same as those of the local file system management method provided in Embodiment 1 above, and will not be repeated here.

[0217] Example 6

[0218] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the local file system management method described above.

[0219] The computer program product provided in this application can solve the technical problem of poor ease of expansion of existing local file systems in cloud storage environments. Compared with the prior art, the beneficial effects of the computer program product provided in the embodiments of this invention are the same as the beneficial effects of the local file system management method provided in the above embodiments, and will not be repeated here.

[0220] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A method for managing a local file system, characterized in that, Each object in the local file system includes multiple file storage areas that store inode data. The management of the local file system includes: Obtain the target file metadata of the target file, and extract the target file name and target file type from the target file metadata; Based on the idle index node queue, obtain the idle index node data and the target index node number corresponding to the idle index node data; The target file metadata is stored in the file storage area corresponding to the free inode data, and a target directory entry is constructed based on the target file name, the target file type, and the target inode number; The target object corresponding to the target file name is determined based on a linear hash function; If the target file name cannot be found in the target object based on the multi-way cuckoo hash function, and there are no free directory entry slots in the target object, then the target object is split based on the linear hash function to create free directory entry slots. Insert the target directory entry into the free directory entry slot to complete the creation of the target file; The step of obtaining idle index node data and the target index node number corresponding to the idle index node data based on the idle index node queue includes: If there is idle index node data in the idle index node queue, then the index node number corresponding to the first index node data pointed to by the head pointer in the idle index node queue is taken as the target index node number, and the index node data corresponding to the target index node number is taken as the idle index node data. If there are no idle index node data in the idle index node queue, a new object is created to store the index node numbers corresponding to the multiple index node data contained in the new object into the idle index node queue, thereby obtaining the target idle index node queue. In the target free index node queue, the index node number corresponding to the first index node data pointed to by the head pointer is taken as the target index node number, and the index node data corresponding to the target index node number is taken as the free index node data.

2. The local file system management method as described in claim 1, characterized in that, The step of determining the target object corresponding to the target filename based on the linear hash function includes: The linear hash function is initialized based on the linear hash variable in the parent directory to calculate the bucket number where the target file name is located; By combining the inode number of the parent directory and the bucket number, the target object number is obtained; Using the target object number as an index, search for the target object corresponding to the target object number in the local file system.

3. The local file system management method as described in claim 2, characterized in that, After the step of combining the inode number of the parent directory and the bucket number to obtain the target object number, the local file system management method further includes: If the target object corresponding to the target object number cannot be found in the local file system using the target object number as an index, then a free object in the local file system is used as the target object and associated with the target object number. Here, the free object refers to an object that has no associated object number.

4. The local file system management method as described in claim 1, characterized in that, The step of splitting the target object based on a linear hash function to create free directory entry slots includes: The target object is split based on the round-robin scheduling algorithm in the linear hash function to create free directory entry slots.

5. The local file system management method as described in claim 1, characterized in that, The step of inserting the target directory entry into the free directory entry slot includes: Obtain the remaining directory entries in the target directory, excluding the target file name; The remaining directory entries are stored from the head of the free directory entry slot, and the target file name is stored from the tail of the free directory entry slot.

6. The method for managing a local file system as described in any one of claims 1 to 5, characterized in that, Following the step of inserting the target directory entry into the free directory entry slot, the local file system management method further includes: In response to a file data read instruction for the target file, the target inode number in the target directory entry is extracted, and the data size and file offset of the file data to be read are obtained; Calculate the logical block number of the file data to be read based on the data size and the file offset; The global object number is obtained by combining the target inode number and the logical block number; Read the file data to be read from the target file from the storage area corresponding to the global object number.

7. The method for managing a local file system as described in any one of claims 1 to 5, characterized in that, Following the step of inserting the target directory entry into the free directory entry slot, the local file system management method further includes: In response to a file information read instruction for the target file, extract the target inode number from the target directory entry; The file information of the target file is read by reading the inode data corresponding to the target inode number.

8. The method for managing a local file system as described in any one of claims 1 to 5, characterized in that, Following the step of inserting the target directory entry into the free directory entry slot, the local file system management method further includes: In response to a file deletion command on the target file, extract the target inode number from the target directory entry; Delete the target file and the target inode number from the file storage area corresponding to the target inode number; The target inode number is inserted into the object storage area pointed to by the tail pointer in the idle inode queue.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the steps of the local file system management method as described in any one of claims 1 to 8.

10. A readable storage medium, characterized in that, The readable storage medium is a computer-readable storage medium, on which a program implementing a local file system management method is stored. The program implementing the local file system management method is executed by a processor to implement the steps of the local file system management method as described in any one of claims 1 to 8.

Images