A NVM local file management system and method based on SIMD instructions
Through the NVM local file management system based on SIMD instructions, the hash structure and SIMD instructions optimization are adopted to solve the problem that the file system performance on NVM devices cannot be fully utilized, and fast indexing and efficient file management are achieved.
Patent Information
- Application Number
- CN202111583926.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-12-22
- Publication Date
- 2025-08-22
- Estimated Expiration
- 2041-12-22
AI Technical Summary
When facing the new storage device NVM, the existing file system fails to effectively utilize its read and write characteristics and SIMD instruction set, resulting in insufficient performance, especially in the indexing process.
An NVM local file management system based on SIMD instructions is designed, using a linear hashed directory data block index module, a static hashed global data block management module, and a SIMD instruction optimized in-block index module, combining SIMD instructions to optimize the data structure to avoid the indexing process memory access caused by the complex memory data structure of traditional file systems.
Through the flat design of the hash structure and the optimization of SIMD instructions, fast indexing within the O(1) time complexity is achieved, memory fetching operations are reduced, read and write amplification problems are avoided, and file system performance is improved.
Smart Images

Figure CN114238226B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of file management, and in particular to a NVM local file management system and method based on SIMD instructions. Background Art
[0002] File systems are a common data organization method and are currently used as the underlying storage system in various fields. For new storage devices like NVM, how to effectively leverage hardware performance based on their read and write characteristics and the high-performance SIMD instruction set remains an unresolved issue in current file system design. Traditional local file systems such as ext4 and xfs only utilize the DAX mechanism for NVM devices, but lack appropriate NVM optimizations in their overall file system design. Summary of the Invention
[0003] In order to solve the above technical problems, the purpose of the present invention is to provide an NVM local file management system and method based on SIMD instructions. A new data block and directory management method is designed according to the read and write characteristics of NVM devices, and SIMD instructions are combined to optimize and improve file system performance.
[0004] The first technical solution adopted by the present invention is: a NVM local file management system based on SIMD instructions, comprising:
[0005] A directory data block indexing module based on linear hashing is used to obtain the logical block number of the directory where the file is located;
[0006] A global data block management module based on static hashing is used to convert logical block numbers into physical block numbers to obtain data blocks;
[0007] The directory block index module based on SIMD instruction optimization is used to accelerate intra-block searches within data blocks using SIMD optimization.
[0008] Furthermore, the specific working steps of the linear hash-based directory data block index module include:
[0009] Initialize linear hashing;
[0010] The splitting process is carried out in a round-robin manner;
[0011] During the directory entry insertion process, the directory block subscript is calculated based on the file name;
[0012] If it is determined that there is a vacant space in the directory block, insert it directly;
[0013] If it is determined that the directory block is full, the overflow directory block is used and the directory entry is inserted into the overflow directory block;
[0014] During the directory indexing process, the hash value is calculated based on the file name to be indexed to obtain the logical block number.
[0015] Furthermore, the specific working steps of the global data block management module based on static hash include:
[0016] Initialize the device and initialize the global data block hash table according to the device capacity;
[0017] During the data block insertion process, the unique block number composed of the inode number and the logical block number is calculated through the hash function, and the hash value is used as the hash table subscript to obtain the corresponding hash item;
[0018] Find the data block based on the hash item.
[0019] Furthermore, the specific working steps of the directory block index module based on SIMD instruction optimization include:
[0020] During the insertion process, a hash value is calculated for the file name of each directory entry, and all hash values in the same block are grouped together;
[0021] The remaining lower 15 bits are the hash value of the file name;
[0022] During the search process within the directory data block, multiple hash values are compared and searched simultaneously based on SIMD instructions to obtain the relative position of the match and locate the location of the directory entry.
[0023] The second technical solution adopted by the present invention is: a NVM local file management method based on SIMD instructions, including the file creation steps:
[0024] Receive a request from an upper-layer application to create a file name;
[0025] Based on the linear hash variables in the parent directory, hash calculation and judgment are performed to obtain the logical data block number where the file name is located;
[0026] Hash the combination of the parent directory's inode number and logical block number to obtain the bucket index of the data block hash table;
[0027] Get the corresponding bucket from the data block hash table according to the bucket index, and use SIMD instructions to search inside the bucket;
[0028] Find the corresponding data block item, obtain the physical block number in the data block item, and read the corresponding data block;
[0029] Read the corresponding hash field from the data block, calculate the hash of the file name and take the lower 15 bits, set the existing bit to 1, and use SIMD instructions to check whether the same name already exists in the block;
[0030] If there is no duplicate name, set the lower 15 bits of the hash to 0 and the existing bit to 1, and use SIMD instructions to find the hash item in the block that is smaller than the value, that is, the corresponding position is free;
[0031] If it is determined that there is no free item, the linear hash data block split is triggered and the linear hash data block split operation is performed;
[0032] When it is determined that there is a free item, the information combination of the new file is inserted into the corresponding empty position through the free position in the block and persisted. The corresponding hash value is updated and persisted to complete the file creation process.
[0033] Furthermore, the file linking step is also included:
[0034] Receive link request for file name from upper layer application;
[0035] Determine whether the link mark bit of the target file inode to be linked has been set to a link file;
[0036] If it is not a linked file, apply for a free inode position in the link inode, migrate the inode data of the target file to be linked to it, make it persistent, and set the link mark position to true in the original inode, and write the physical address of the corresponding inode data;
[0037] If it is a link file, the file name is hashed and judged based on linear hash to obtain the logical data block number where the file name is located;
[0038] Hash the combination of the parent directory's inode number and the logical block number obtained in the previous step to obtain the bucket index of the data block hash table;
[0039] Get the corresponding bucket from the data block hash table according to the bucket index, and use SIMD instructions to search inside the bucket;
[0040] If no corresponding data block entry is found, apply for a free data block in the data block bitmap and insert the obtained physical address into the corresponding data block entry in the bucket;
[0041] Find the corresponding data block item, obtain the physical block number in the data block item, and read the corresponding data block;
[0042] Read the corresponding hash field from the data block, calculate the hash of the file name and take the lower 15 bits, set the existing bit to 1, and use SIMD instructions to check whether the same name already exists in the block;
[0043] If there is no duplicate name, set the lower 15 bits of the hash to 0 and the existing bit to 1, and use SIMD instructions to find the hash item in the block that is smaller than the value, that is, the corresponding position is free;
[0044] If it is determined that there is no free item, the linear hash data block split is triggered and the linear hash data block split operation is performed.
[0045] If a free entry is found, a new file inode is assembled, the link mark position of the new file inode is set to true, and the physical address of the target inode to be linked is written in the link inode;
[0046] Through the free space in the block, the inode and directory entry information of the new file are inserted into the corresponding empty space and persisted. The corresponding hash value is updated and persisted to complete the file link process.
[0047] Furthermore, the file reading step is also included:
[0048] Receive a read request for a file name from an upper-layer application;
[0049] Perform hash calculation and judgment on the file name based on linear hash to obtain the logical data block number where the file name is located;
[0050] The inode number and logical block number of the parent directory are combined and hashed to obtain the bucket index of the data block hash table;
[0051] Get the corresponding bucket from the data block hash table according to the bucket index, and use SIMD instructions to search inside the bucket;
[0052] Find the corresponding data item, obtain the physical block number in the data block item, and read the corresponding data block;
[0053] Read the corresponding hash field from the data block, calculate the hash of the file name and take the lower 15 bits, set the existing bit to 1, and use SIMD instructions to check whether it exists in the block;
[0054] If it is determined to exist, the corresponding inode and directory entry information is read from the data block according to the inode location, and the file name is compared;
[0055] If the file names are the same, determine whether the link mark bit of the corresponding inode is a link file;
[0056] Determine that it is a link file and read the physical address of the entity inode in the link inode from the link file;
[0057] If it is not a link file, read the corresponding inode data and return it to the user.
[0058] The beneficial effects of the system and method of the present invention are as follows: the present invention fully considers the characteristics of NVM device performance being similar to DRAM performance, redesigns the data block management and directory management methods, avoids the problem of large-scale memory access during the indexing process caused by the use of complex memory data structures in traditional file systems, and combines the SIMD instruction set to specifically design data structures for calculation acceleration optimization. BRIEF DESCRIPTION OF THE DRAWINGS
[0059] Figure 1 This is a flowchart of the steps for creating a file according to a specific embodiment of the present invention;
[0060] Figure 2 This is a flowchart of the steps of file linking in a specific embodiment of the present invention;
[0061] Figure 3 It is a flowchart of the steps of file reading in a specific embodiment of the present invention. DETAILED DESCRIPTION
[0062] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The step numbers in the following embodiments are provided for ease of description only and do not limit the order of the steps. The order of execution of the steps in the embodiments can be adaptively adjusted based on the understanding of those skilled in the art.
[0063] (1) A directory data block indexing module based on linear hashing, used to obtain the logical block number of the directory where the file is located;
[0064] For the directory management of the file system, that is, for file operations, it is first necessary to obtain the logical block number in the parent directory through the file name. Since the directory size has a dynamic change problem, the present invention uses a dynamic hashing method of linear hashing for directory indexing of directory data blocks.
[0065] Linear hashing is a dynamic hashing method that can handle the problem of hash table growth with less overhead than static hashing. Linear hashing uses a bucket (a bucket corresponds to a directory data block in the file system) during initialization. At this time, level = 0, next = 0, 2 level The number of buckets in this round, next points to the next bucket index of the split, and the splitting process is carried out in a round-robin manner. Let H level (filename)=h(filename)%2 level , in the process of inserting directory entries, first calculate H according to filename level(filename) gets the bucket index. If there is a vacancy in the bucket, insert it directly. If the bucket is full, use the overflow bucket and insert the directory entry into the overflow bucket. During the continuous insertion process, once a data block overflows, the split threshold is reached, and the next corresponding bucket will be split. During the splitting process, the filename of each directory entry in the bucket will be traversed, and H level+1 (filename) recalculates the bucket index and migrates the directory entry to the corresponding bucket. This way, each split only involves the migration of data in one bucket (which may also include overflow buckets), without involving the entire hash table data. This is the advantage of dynamic hashing. After the split is completed, add 1 to next. If next = 2 level , it means that the split has completed one round. At this time, level is increased by 1, next is assigned to 0, and the split starts from a new round. In the directory indexing process, the hash value is calculated based on the filename to be indexed, and idx = H level (filename), there are two cases: 1. If idx ≥ next, it means that the current bucket [idx] has not been split, so the directory entry corresponding to filename must be inside bucket [idx] and can be directly searched in the block; 2. If idx < next, it means that bucket [idx] has been split, and it is necessary to calculate H level+1 (filename) gets the specific bucket index.
[0066] Using linear hashing for directory data block indexing has the following advantages: 1. Linear hashing is a dynamic hashing strategy. During the growth of the hash table, only a single bucket of data is migrated each time. Unlike the rehash of static hashing, the entire hash table will not be changed, which is beneficial for dynamically changing structures such as directories. 2. Linear hashing does not need to store a large amount of index data like other dynamic hashes. For example, the directory structure of extensible hashing only needs to store the two values level and next, which is convenient for storing fixed-length structures such as inodes without introducing additional structures. 3. Linear hashing is essentially a hash structure. Under normal circumstances, it can directly locate the directory data block where the filename is located in O(1) time. It does not need to search layer by layer like a tree structure, and there is no need for multiple device accesses and memory access overhead caused by binary search within each layer.
[0067] However, linear hashing uses a round-robin method for sequential splitting, and cannot split overflow buckets in real time. Therefore, a temporary overflow bucket is needed to store the current overflowed directory entries. The temporary overflow bucket will not be recycled until it is the turn of the bucket to split. To address this problem, when a bucket overflows, an idle data block will be requested from the data block management module as the overflow bucket, and the address of this data block will be stored in the original bucket for subsequent search.
[0068] (2) A global data block management module based on static hashing, used to convert logical block numbers into physical block numbers to obtain data blocks;
[0069] After obtaining the logical block number in the directory where the file is located, it needs to be converted into a physical block number and then read from the device. This is the data management problem of the file system. Traditional local file systems organize index structures for individual files or directories in data block management, such as extent tree or radix tree. The reason why the tree index structure is commonly used is that the size of a single file or directory will dynamically expand and contract, and the use of a tree structure can flexibly deal with this problem. However, combined with the above analysis, the introduction of a tree index structure will cause multiple memory access problems. To address this situation, the present invention proposes a global data block management method based on hash. Hash is a flat structure. During the indexing process, the data block position can be located at one time by calculating the hash value, avoiding the layer-by-layer search of the tree structure and the multiple memory access overhead caused by the binary search within each layer. At the same time, in order to deal with the problem of dynamic changes in the size of a single file or directory, the present invention uses a global data block management method. Since the number of global data blocks is fixed, it can be effectively combined with a static hash method to achieve fast indexing.
[0070] Specifically, during device initialization, the file system initializes a global data block hash table based on the device capacity. The hash table consists of N hash entries, each of which contains a mapping from a globally unique data block ID to a physical block address. A globally unique block ID consists of an inode number and a logical block number, and is hereafter referred to as an unbid (uniqueblock ID). Using hashing inevitably introduces hash conflicts, which are resolved using a linear probing approach. During data block insertion, for each unbid, a hash value h(unbid) % N is calculated using a hash function. This hash value is used as the hash table index to obtain the corresponding hash entry. This approach falls into two categories: 1. If the hash entry is empty or the unbids are equal, the entry is inserted directly; 2. If the hash entry is not empty and the unbids are not equal, a hash conflict occurs. A linear probing approach is used to resolve the conflict, searching linearly downward from the current hash table position until the first empty hash entry is found, at which point the entry is inserted. Using a linear probing approach to resolve conflicts effectively avoids data migration. Since the hash table must be stored persistently in NVM, data migration results in multiple NVM read and write operations, severely degrading performance. The use of the linear probing method mainly increases the read operations. The hash table can be cached in memory to improve performance, but when the conflict rate is high, it will also cause the problem of multiple memory accesses during the search process. In order to further reduce hash conflicts, the present invention proposes two optimization methods: 1. Set a suitable load factor when initializing the hash table size. Assuming that the number of data blocks in the device is M, the number of hash items in the hash table is set to N during initialization. M / N represents the load factor. Generally, the smaller the load factor, the lower the conflict rate, but the more extra space the hash table wastes; 2. Use bucket multi-way search to reduce the conflict rate, such as Figure 1 As shown, the hash table is divided into n buckets, each containing m hash items. Each hash index directly locates the bucket and is inserted directly when there is a vacant space in the bucket. A conflict is considered only when the bucket is full. This method can effectively reduce the conflict rate, but it introduces traversal search overhead within the bucket. To avoid this problem, the present invention proposes an optimization method combined with SIMD instructions, using a single instruction to simultaneously search for m items within the bucket, reducing the conflict rate while also ensuring performance.
[0071] (3) A directory block index module based on SIMD instruction optimization is used to accelerate intra-block searches within data blocks using SIMD optimization.
[0072] To solve the problem of searching for specific entries and inodes in directory blocks read from the device, traditional local file systems such as ext4 use traversal search directly in the directory blocks, which will bring a large number of memory access operations, and each time the entire data block is read into the memory, there will be a read amplification problem. To solve this problem, the present invention proposes an indexing method in directory data blocks based on SIMD instruction optimization. The structure of the directory data block is as follows: Figure 2 As shown in the figure: During the insertion process, a hash value is calculated for the filename of each directory entry, and all hash values within the same block are grouped together. Each hash value is 16 bits, with the upper bit being the exist bit, indicating whether the bit is occupied. The remaining lower 15 bits are the lower 15 bits of the filename hash value. During the search process within the directory data block, the characteristics of SIMD instructions are utilized. A single instruction can compare and search multiple hash values simultaneously. After obtaining the relative position of the match, the directory entry can be directly located. Only two read operations are required: one hash value read and one directory entry read. Moreover, the byte addressing characteristics of NVM devices can be utilized. There is no need to read the entire data block into memory for each search. Instead, only the corresponding data segment to be read is read during the search process, avoiding the read amplification problem.
[0073] To further improve system performance, the present invention proposes a solution that merges directory entries and file inodes. Because traditional local file systems store entries and inodes separately, file path lookups require first using the file name to find the corresponding directory entry through a directory index, then reading the corresponding inode number from the entry, and finally reading the corresponding inode from the inode data block using the inode number. Similarly, during file creation, entries and inodes must be written separately. Therefore, merging entries and inodes can effectively reduce NVM device reads and writes, accelerating the creation and search process. Furthermore, since entries and inodes themselves have very small data volumes, writing them separately can cause NVM write amplification. Merging them together can achieve the minimum NVM write unit, avoiding this problem. However, merging entries and inodes presents significant challenges for link operations. Therefore, the present invention introduces link inodes, specifically designed to manage the storage and management of linked inode data. When a file has a link, the link inode takes over and stores the inode in its own data block. All directory entries linked to this inode that contain the inode's physical address can then be directly found. Although this solution degenerates into separate storage methods for files containing links, such as entries and inodes, it still enjoys the performance improvement brought by merging the two and the advantage of avoiding NVM write amplification for the largest number of ordinary files in the file system.
[0074] A method for managing NVM local files based on SIMD instructions includes the steps of device address space layout, file creation, file linking and file reading.
[0075] The device address space layout of the present invention divides the continuous address space of the NVM into the following parts: super block, root inode, link inode, data block table, data block bitmap, and data block. The superblock stores file system metadata information, the root inode is the root directory inode data, the link inode is specifically used to store link file inode data, the data block table is the data block hash table, the data block bitmap is the data block bitmap, and the data block is the data block area.
[0076] File creation steps:
[0077] like Figure 1 Shows the specific process of file creation
[0078] Step 1: Receive a create request from the upper-layer application for the file filename and jump to step 2;
[0079] Step 2: Based on the next and level variables of the linear hash in the parent directory, hash the file name and make a judgment: ln = H level (filename)≥next? H level (filename): H level+1 (filename), get the logical data block number ln where the file name is located, and jump to step 3;
[0080] Step 3: Hash the inode number of the parent directory and the logical block number combination (ino+ln) obtained in step 2 to obtain the bucket index of the data block hash table, and jump to step 4;
[0081] Step 4: Get the corresponding bucket from the data block hash table for the index calculated in step 3, and use SIMD instructions to search inside the bucket. If the corresponding data block item can be found, jump directly to step 6, otherwise jump to step 5;
[0082] Step 5: Apply for a free data block in the data block bitmap, insert the obtained physical block number into the data block item corresponding to the bucket obtained in step 3, and jump to step 6;
[0083] Step 6: Get the physical block number in the data block item, read the corresponding data block, and jump to step 7;
[0084] Step 7: Read the corresponding hash field from the data block, calculate the hash of the filename and take the lower 15 bits, set the exist bit to 1, and use SIMD instructions to find out whether there is a duplicate name in the block (if there is an overflow data block, it is necessary to search in the overflow block again). If so, directly return a duplicate name error; otherwise, jump to step 8.
[0085] Step 8: Set the lower 15 bits of the hash to 0 and the exist bit to 1. Use SIMD instructions to search for hash items in the block that are less than the value, that is, the corresponding position is free (if there is an overflow data block, it is necessary to search in the overflow block again). If there is no free item, jump to step 9, otherwise, jump to step 10.
[0086] Step 9: Trigger the linear hash data block split and perform the linear hash data block split operation. After the split is completed, return to step 2;
[0087] Step 10: Using the free space in the block obtained in step 8, insert the new file's inode, entry, and other information into the corresponding empty space and persist it. Then, update the corresponding hash value and persist it. At this point, the file creation process is completed.
[0088] File linking steps:
[0089] like Figure 2 Shows the specific process of file linking
[0090] Step 1: Receive a link request from the upper-layer application for the file named filename and jump to step 2;
[0091] Step 2: Determine whether the is_link flag of the target file inode to be linked has been set to a link file. If it is not a link file, jump to step 3, otherwise jump to step 4;
[0092] Step 3: Apply for a free inode location in the link inode, migrate the inode data of the target file to be linked to it, and make it persistent. Set the is_link flag to true in the original inode and write the physical address of the corresponding inode data, then jump to step 4.
[0093] Step 4: Based on the next and level variables of the linear hash in the parent directory of filename, perform hash calculation and judgment on the filename: ln = H level (filename)≥next? H level (filename): H level+1 (filename), get the logical data block number ln where the file name is located, and jump to step 5;
[0094] Step 5: Hash the inode number of the parent directory and the logical block number combination (ino+ln) obtained in the previous step to obtain the bucket index of the data block hash table and jump to step 6;
[0095] Step 6: Get the corresponding bucket from the data block hash table for the index calculated in the previous step, and use SIMD instructions to search inside the bucket. If the corresponding data block item can be found, jump directly to step 8, otherwise jump to step 7;
[0096] Step 7: Apply for a free data block in the data block bitmap, insert the obtained physical address into the data block item corresponding to the bucket obtained in step 5, and jump to step 8;
[0097] Step 8: Get the physical block number in the data block item, read the corresponding data block, and jump to step 9;
[0098] Step 9: Read the corresponding hash field from the data block, calculate the hash of the filename and take the lower 15 bits, set the exist bit to 1, and use SIMD instructions to find out whether there is a duplicate name in the block (if there is an overflow data block, it is necessary to search in the overflow block again). If so, directly return a duplicate name error; otherwise, jump to step 10.
[0099] Step 10: Set the lower 15 bits of the hash to 0 and the exist bit to 1. Use SIMD instructions to search for hash items in the block that are smaller than the value, that is, the corresponding position is free (if there is an overflow data block, it is necessary to search in the overflow block again). If there is no free item, jump to step 11, otherwise, jump to step 12.
[0100] Step 11: Trigger the linear hash data block split and perform the linear hash data block split operation. After the split is completed, return to step 4;
[0101] Step 12: Assemble the new file inode, set the is_link flag of the new file inode to true and write the physical address of the target inode to be linked in the link inode, and jump to step 13;
[0102] Step 13: Insert the new file's inode, entry, and other information into the corresponding empty space using the previously obtained free space in the block, persist it, and then update the corresponding hash value and persist it. This completes the file linking process.
[0103] File reading steps:
[0104] like Figure 3 Shows the specific process of file reading
[0105] Step 1: Receive a read request from the upper-layer application for the file filename and jump to step 2;
[0106] Step 2: Based on the next and level variables of the linear hash in the parent directory, hash the file name and make a judgment: ln = H level (filename)≥next? H level (filename): H level+1 (filename), get the logical data block number ln where the file name is located, and jump to step 3;
[0107] Step 3: Hash the inode number of the parent directory and the logical block number combination (ino+ln) obtained in step 2 to obtain the bucket index of the data block hash table, and jump to step 4;
[0108] Step 4: Use the index calculated in step 3 to get the corresponding bucket in the data block hash table, and use SIMD instructions to search within the bucket. If the corresponding data block item can be found, jump directly to step 5, otherwise it returns that the file does not exist;
[0109] Step 5: Get the physical block number in the data block item, read the corresponding data block, and jump to step 6;
[0110] Step 6: Read the corresponding hash field from the data block, calculate the hash of the file name filename and take the lower 15 bits, set the exist bit to 1, and use SIMD instructions to check whether it exists in the block (if there is an overflow data block, it is necessary to search in the overflow block again). If it does not exist, directly return that the file does not exist. Otherwise, jump to step 7.
[0111] Step 7: Based on the inode location obtained in the previous step, read the corresponding inode and entry information from the data block and compare the filenames. If the filenames are different, return that the file does not exist. Otherwise, jump to step 8.
[0112] Step 8: Determine whether the is_link flag of the corresponding inode is a link file. If so, jump to step 9, otherwise, jump to step 10;
[0113] Step 9: Read the physical address of the entity inode in the link inode from the link file;
[0114] Step 10: Read the corresponding inode data and return it to the user.
[0115] The contents of the above system embodiments are all applicable to the present system embodiments. The functions specifically implemented by the present method embodiments are the same as those of the above system embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.
[0116] The present invention uses a hash-based method to redesign the file system data block index and directory index structure. The flattened hash structure can ensure indexing within O(1) time complexity and does not require multiple memory access operations caused by layer-by-layer search and binary search at each layer as in the traditional tree structure. In addition, the structure fully utilizes the characteristics of the SIMD instruction set, including using SIMD instructions in the data block index structure to perform multi-way search within the bucket, and using SIMD instructions in the directory data block to search and match multiple hashes at one time, thereby improving system performance.
[0117] In terms of data structure design, the characteristics of NVM devices are fully taken into account, and the index structure and specific data are stored separately. When reading, the byte addressing function of NVM can be used for targeted reading, avoiding the read amplification problem. The entry and inode data are stored together to avoid the write amplification problem when writing data, effectively reduce the number of device reads and writes, and reduce file creation and reading delays.
[0118] A NVM local file management device based on SIMD instructions:
[0119] at least one processor;
[0120] at least one memory for storing at least one program;
[0121] When the at least one program is executed by the at least one processor, the at least one processor implements the above-mentioned NVM local file management method based on SIMD instructions.
[0122] The contents of the above method embodiments are all applicable to the present device embodiments. The functions specifically implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.
[0123] A storage medium stores processor-executable instructions, wherein the processor-executable instructions are used to implement the above-mentioned NVM local file management method based on SIMD instructions when executed by the processor.
[0124] The contents of the above method embodiments are all applicable to the present storage medium embodiment. The functions specifically implemented by the present storage medium embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.
[0125] The above is a specific description of the preferred implementation of the present invention, but the invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of this application.
Claims
1. A NVM local file management system based on SIMD instructions, characterized in that: include: A directory data block indexing module based on linear hashing is used to obtain the logical block number of the directory where the file is located; A global data block management module based on static hashing is used to convert logical block numbers into physical block numbers to obtain data blocks; The directory block index module based on SIMD instruction optimization is used to accelerate the search within the data block by using SIMD optimization; The specific working steps of the linear hash-based directory data block index module include: Initialize linear hashing; The splitting process is carried out in a round-robin manner; During the directory entry insertion process, the directory block subscript is calculated based on the file name; If it is determined that there is a vacant space in the directory block, insert it directly; If it is determined that the directory block is full, the overflow directory block is used and the directory entry is inserted into the overflow directory block; During the directory indexing process, the hash value is calculated based on the file name to be indexed to obtain the logical block number; The specific working steps of the global data block management module based on static hashing include: Device initialization, using the load factor as a limit, initializes the global data block hash table according to the device capacity; During the data block insertion process, the unique block number composed of the inode number and the logical block number is calculated through the hash function, and the hash value is used as the hash table subscript to obtain the corresponding hash item; Find the data block based on the hash item; The specific working steps of the directory block index module based on SIMD instruction optimization include: During the insertion process, a hash value is calculated for the file name of each directory entry, and all hash values in the same block are grouped together; The remaining lower 15 bits are the hash value of the file name; During the search process within the directory data block, multiple hash values are compared and searched simultaneously based on SIMD instructions to obtain the relative position of the match and locate the location of the directory entry.
2. A NVM local file management method based on SIMD instructions, characterized in that: The NVM local file management system based on SIMD instructions as claimed in claim 1 includes the following steps of creating a file: Receive a request from an upper-layer application to create a file name; Based on the linear hash variables in the parent directory, hash calculation and judgment are performed to obtain the logical data block number where the file name is located; Hash the combination of the parent directory's inode number and logical block number to obtain the bucket index of the data block hash table; Get the corresponding bucket from the data block hash table according to the bucket index, and use SIMD instructions to search inside the bucket; Find the corresponding data block item, obtain the physical block number in the data block item, and read the corresponding data block; Read the corresponding hash field from the data block, calculate the hash of the file name and take the lower 15 bits, set the existing bit to 1, and use SIMD instructions to check whether the same name already exists in the block; If there is no duplicate name, set the lower 15 bits of the hash to 0 and the existing bit to 1, and use SIMD instructions to find the hash item in the block that is smaller than the value, that is, the corresponding position is free; If it is determined that there is no free item, the linear hash data block split is triggered and the linear hash data block split operation is performed; When it is determined that there is a free item, the information combination of the new file is inserted into the corresponding empty position through the free position in the block and persisted. The corresponding hash value is updated and persisted to complete the file creation process.
3. The NVM local file management method based on SIMD instructions according to claim 2, characterized in that: Also includes the file linking step: Receive link request for file name from upper layer application; Determine whether the link mark bit of the target file inode to be linked has been set to a link file; If it is not a linked file, apply for a free inode position in the link inode, migrate the inode data of the target file to be linked to it, make it persistent, and set the link mark position to true in the original inode, and write the physical address of the corresponding inode data; If it is a link file, the file name is hashed and judged based on linear hash to obtain the logical data block number where the file name is located; Hash the combination of the parent directory's inode number and the logical block number obtained in the previous step to obtain the bucket index of the data block hash table; Get the corresponding bucket from the data block hash table according to the bucket index, and use SIMD instructions to search inside the bucket; If no corresponding data block entry is found, apply for a free data block in the data block bitmap and insert the obtained physical address into the corresponding data block entry in the bucket; Find the corresponding data block item, obtain the physical block number in the data block item, and read the corresponding data block; Read the corresponding hash field from the data block, calculate the hash of the file name and take the lower 15 bits, set the existing bit to 1, and use SIMD instructions to check whether the same name already exists in the block; If there is no duplicate name, set the lower 15 bits of the hash to 0 and the existing bit to 1, and use SIMD instructions to find the hash item in the block that is smaller than the value, that is, the corresponding position is free; If it is determined that there is no free item, the linear hash data block split is triggered and the linear hash data block split operation is performed; if it is determined that there is a free item, a new file inode is assembled, the link mark position of the new file inode is true and the physical address of the target inode to be linked in the link inode is written; Through the free space in the block, the inode and directory entry information of the new file are inserted into the corresponding empty space and persisted. The corresponding hash value is updated and persisted to complete the file link process.
4. The NVM local file management method based on SIMD instructions according to claim 3, characterized in that: Also includes the file reading step: Receive a read request for a file name from an upper-layer application; Perform hash calculation and judgment on the file name based on linear hash to obtain the logical data block number where the file name is located; The inode number and logical block number of the parent directory are combined and hashed to obtain the bucket index of the data block hash table; Get the corresponding bucket from the data block hash table according to the bucket index, and use SIMD instructions to search inside the bucket; Find the corresponding data item, obtain the physical block number in the data block item, and read the corresponding data block; Read the corresponding hash field from the data block, calculate the hash of the file name and take the lower 15 bits, set the existing bit to 1, and use SIMD instructions to check whether it exists in the block; If it is determined to exist, the corresponding inode and directory entry information is read from the data block according to the inode location, and the file name is compared; If the file names are the same, determine whether the link mark bit of the corresponding inode is a link file; Determine that it is a link file and read the physical address of the entity inode in the link inode from the link file; If it is not a link file, read the corresponding inode data and return it to the user.
Citation Information
Patent Citations
Chain log storage structure, hash index structure and data operation method thereof, server and medium
CN107515901A
Cuckoo Hash-based file system directory management method and system
CN113094336A