A method, product, device and storage medium for a multi-host shared file system

Abstract

The present invention discloses a method, product, device and storage medium for multi-host shared file systems, relating to the field of computer technologies. It includes configuring a shared memory device as a character device, directly mapping it to the user-mode virtual address space, bypassing the kernel page cache, and directly reading and writing the physical address of the shared memory, fundamentally avoiding multi-host cache conflicts. When formatting, the shared memory is divided into a superblock area, a metadata area, a log area, and a data area, and all hosts uniformly operate through the shared metadata area to avoid single-machine cache interference. When mounting, a hidden metadata file is created to map the non-data area, and the log entries are scanned to reconstruct the directory file structure, enabling all hosts to generate a directory file structure that is exactly the same as the shared memory through log replay, solving the data consistency problem of traditional multi-host file systems caused by cache policies, achieving the effect of multi-host sharing a unified memory view, real-time synchronization of operations, and reducing data access latency.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular, to a method, product, device, and storage medium for a multi-host shared file system. Background Art

[0002] As the basis for data storage and management, the file system is an important part of the operating system. The basic architecture of the file system is usually divided into two layers: the upper layer provides a unified interface through the virtual file system; the lower layer is connected to the storage device to manage the physical structure, logical objects, and access control of the device. The upper and lower layers work together to provide stable and efficient file services for application programs.

[0003] Currently, for the scenario of multi-host shared storage devices, generally, the fsdax (existing in the form of a block device) technology is used to build a file system on a shared memory device that supports the CXL (Compute Express Link) protocol and allows multiple hosts to mount simultaneously. However, this solution only achieves superficial sharing. That is, after the host mounts, due to the design concept of the traditional file system based on caching and write-back strategies, its kernel always assumes that the local cached data is exactly the same as the data on the storage device. In the scenario of frequent concurrent modifications by multiple hosts, the cache of one host cannot immediately perceive the direct modifications of other hosts to the shared device, resulting in inconsistent data between the cache and the storage device. This lack of cache consistency makes the file system unable to maintain a unified global state among multiple hosts, ultimately leading to data conflicts, access errors, or file corruption, and unable to meet the true multi-host collaboration requirements.

[0004] Therefore, how to provide a solution to the above technical problems is an issue that those skilled in the art need to solve currently. Summary of the Invention

[0005] The present invention provides a method, product, device, and storage medium for a multi-host shared file system to at least solve the data consistency problem of the multi-host file system caused by the caching strategy in related technologies.

[0006] The present invention provides a method for multi-host shared file system. Multiple hosts are connected to a shared memory device. Applied to any of the above-mentioned hosts, the method for multi-host shared file system includes: in response to being the master node, configuring the shared memory device as a character device, mapping the physical memory corresponding to the character device to the user-mode virtual address space, and formatting the character device to divide the physical memory into a superblock area, a metadata area, a log area, and a data area; in response to being the master node or a slave node, performing a mounting operation, where the mounting operation includes: reading the information of the superblock area, generating the root directory of the virtual file system based on the information, creating a hidden metadata file under the preset mounting point path and mapping it to the non-data area of the physical memory, and scanning all log entries in the log area to reconstruct a directory file structure globally consistent with the shared memory device in the local memory.

[0007] The present invention also provides a computer program product, including computer programs / instructions, which when executed by a processor implement the steps of any of the above-mentioned methods for multi-host shared file system.

[0008] The present invention also provides an electronic device, including: a memory for storing a computer program; a processor for implementing the steps of any of the above-mentioned methods for multi-host shared file system when executing the computer program.

[0009] The present invention also provides a computer-readable storage medium, in which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of any of the above-mentioned methods for multi-host shared file system.

[0010] Through the present invention, since the shared memory device is configured as a character device and directly mapped to the user-mode virtual address space, bypassing the kernel page cache and directly reading and writing the physical address of the shared memory, multi-host cache conflicts are fundamentally avoided. When formatting, the shared memory is divided into a superblock area, a metadata area, a log area, and a data area. All hosts uniformly operate through the shared metadata area to avoid single-machine cache interference. When mounting, a hidden metadata file is created to map the non-data area, and the log entries are scanned to reconstruct the directory file structure, so that all hosts generate a directory file structure completely consistent with the shared memory through log replay, solving the data consistency problem caused by the cache policy in the traditional multi-host file system, achieving a unified memory view for multi-host sharing, real-time synchronization of operations, and reducing the data access latency. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1 A flowchart of the steps of a method for multiple hosts to share a file system is provided in an embodiment of the present invention.

[0013] Figure 2 A diagram of the file system architecture provided by an embodiment of the present invention.

[0014] Figure 3 This is a diagram of the disk structure after being formatted by the file system provided by an embodiment of the present invention.

[0015] Figure 4 This is a flowchart of the second file system mounting method provided by an embodiment of the present invention.

[0016] Figure 5 A schematic diagram of a file system management structure provided by an embodiment of the present invention.

[0017] Figure 6 A schematic diagram of a file system file log entry structure and file lock provided by an embodiment of the present invention.

[0018] Figure 7 A schematic diagram of multi-host concurrent access contention provided by an embodiment of the present invention.

[0019] Figure 8 A schematic diagram of an application of dirty locks in file system log replay provided by an embodiment of the present invention.

[0020] Figure 9 A schematic diagram of the effect of a file system log bitmap lock when creating file contention is provided in an embodiment of the present invention.

[0021] Figure 10 A schematic diagram of the effect of a file system log bitmap lock when creating file contention is provided in an embodiment of the present invention.

[0022] Figure 11 A schematic diagram of a file system lazy deletion process provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0023] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present invention.

[0024] It should be noted that in the description of the present invention, the terms "include", "comprise" or any other variation thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in the present invention are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0025] In order to enable those skilled in the art of the present technology to better understand the solution of the present invention, the present invention will be further described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0026] An embodiment of the present invention provides a method for a multi-host shared file system. In combination with the execution process of the method for the multi-host shared file system, the method will be described in detail. Please refer to Figure 1 The method for the multi-host shared file system includes:

[0027] S101: In response to being the master node itself, configure the shared memory device as a character device, map the physical memory corresponding to the character device to the user-mode virtual address space, and format the character device to divide the physical memory into a superblock area, a metadata area, a log area, and a data area.

[0028] In this embodiment, the shared memory device may specifically be a CXL shared memory device (i.e., CXL Region). For each host in the multi-host, the identity information includes a master node or a slave node. Correspondingly, the file system in the present invention (hereinafter referred to as cxlfs) is a multi-host shared file system based on the CXL3.0 protocol and stored on the CXL shared memory device. It can be understood that the formatting can only be executed and take effect once. The host that first completes the formatting will obtain the owner identity (master node), and the remaining hosts that mount and use it will obtain the user identity (slave node).

[0029] Specifically, the master node is the host among multiple hosts that can format the character device to divide the physical memory into a superblock area, a metadata area, a log area, and a data area. Specifically, when a certain host performs the first formatting operation on the shared memory device, this host is automatically designated as the master node. Any subsequent host that mounts this shared memory device will automatically become a slave node by reading the information in the superblock area during the mounting process. Taking three hosts as an example, the three hosts are host A, host B, and host C respectively. Host A formats the CXL shared memory device for the first time and can write its own UUID (Universally Unique Identifier) into the superblock area as the master node. When host B and host C mount, they read the superblock area and find that the master node is host A, so they mark themselves as slave nodes.

[0030] It can be understood that cxlfs completes the formatting of the file system based on the devdax character device. The user space will also provide a cxlfs checking tool. After cxlfs is initialized, the specific information of each CXL Region can be viewed through the cxlfs checking tool, including identity information, logs, and the space usage of physical pages, etc. Specifically, referring to Figure 2 , the CXL Region is provided to the upper-layer operating system in the devdax mode (existing in the form of a character device). cxlfs formats the file system based on the devdax device and is managed by the upper-layer VFS (Virtual File System). The user space completes specific operations such as files and directories through the user-space tools provided by cxlfs. Based on the CXL switch, multiple hosts can share the CXL Region. Therefore, cxlfs stored in the devdax device can be shared among multiple hosts.

[0031] Specifically, the formatting process of the cxlfs file system is a process of initializing the CXL Region memory based on the devdax (a CXL Region mode existing in the form of a character device) device. The formatting operation of cxlfs refers to the initialization of the CXL Region structure based on the devdax device. The devdax device can be mapped to a large linear space, and the formatting process is a process of dividing the structure of this linear space. After cxlfs is formatted, the devdax will be sequentially divided into a superblock area (superblock), a metadata area (meta), a log area (log), and a data area (data) from the low address to the high address.

[0032] Referring to Figure 3, The superblock is a key data structure that describes cxlfs. cxlfs creates and assigns values to the superblock during formatting. The superblock is used to store important information about the file system, such as: system identity information (the host that performs the formatting operation is the master node, and the rest are slave nodes), system unique identifier, file system identifier, starting addresses of each area, etc. Once the superblock is created, it is not allowed to be modified.

[0033] The metadata area stores the metadata related to cxlfs operations. The two core structures are the bitmap and the lock. cxlfs provides two types of bitmaps in the metadata area. One is the log bitmap, which is used to manage the space utilization of the log area. The other is the page bitmap, which is used to manage the free space in the data area. Due to the linear space characteristics of devdax, the bitmaps are stored using a fixed-length one-dimensional array and manage a limited number of log and page spaces. The lock in the metadata acts on the log bitmap and is a means to ensure data security for multi-host concurrent execution of cxlfs file structure modification operations. Multiple hosts compete for the lock to obtain the permission to modify the bitmap, and the cache coherence feature of the CXL3.0 protocol ensures the visibility and atomicity of the lock competition process. The metadata area also stores common information such as the number of log entries and the number of file data blocks.

[0034] The log area is formatted as a list of log entries. The list should store a fixed number of log entries (the number is explicitly set during cxlfs formatting), and each log entry has the same size to meet the unified management of the log bitmap in the metadata area. The log entry list stores two different types of log entries, namely file log entries and directory log entries. File log entries record the key information of a file, including the file name, the offset of the directory entry to which the file belongs, the file size, and the list of file data blocks, etc. The information saved through file log entries can provide an overview of this file. Directory log entries record the key information of a directory, including the directory name, the parent-child directory index, the list of files in the directory, etc. Figure 3 shows the relationship between a list of log entries. From Figure 3 it can be seen that the current file system storage depth is three layers. The top layer stores a directory, under which there is a file and a subdirectory, and there is still a file under the subdirectory. In the linear space of the log area, since the log entry size is fixed, logical pointers can be described by means of address offset indexing. It should be noted that this method does not allow users to create files in the directory without limit, and there is a maximum number of supported files set to meet the requirements of the fixed-length array for log indexing.

[0035] The data area is formatted as a logically linear list, and the list items are logical data blocks (extent, that is Figure 3The data blocks in it), each logical data block consists of a starting address offset parameter and a length parameter, representing a piece of real physical area on the CXL Region. The basic allocation unit of the data area space is a physical page of a fixed size (page). The logical data blocks are tiled on several physical pages, and the real data of the cxlfs file is stored in the physical space described by the data blocks. cxlfs manages the free space of physical pages through the page bitmap in the log area. The number of physical pages is specified during cxlfs formatting. Each bit of the page bitmap represents a physical page. When using it, a physical page needs to be applied first, and then a logical data block is constructed to describe a certain area on the physical page, so that the starting physical address of the logical data block and the physical page will always be aligned. The inode (index node) of the cxlfs file maintains a list of logical data blocks to map the real data to the physical pages corresponding to the data blocks. In this way, the basic file data storage of cxlfs is realized. At the same time, in a multi-host environment, the inodes on the local memories of different hosts will, based on the list of logical data blocks, address the same physical pages in the CXL Region at the same time, thus realizing file sharing.

[0036] The disk structure of cxlfs is described above. cxlfs provides a shared file system service for the upper-layer multi-host environment through the mutual cooperation of the superblock area, the metadata area, the log area, and the data area.

[0037] S102: In response to being the master node or the slave node, execute the mounting operation, and the mounting operation includes: reading the information in the superblock area, generating the root directory of the virtual file system based on the information, creating a hidden metadata file under the preset mounting point path and mapping it to the non-data area of the physical memory, and scanning all the log entries in the log area to reconstruct the directory file structure that is globally consistent with the shared memory device in the local memory.

[0038] In this embodiment, whether it is the host acting as the master node or the host acting as the slave node, it is necessary to mount cxlfs first to use the file management function. The cxlfs mounting operation usually accepts two parameters. One is the formatted devdax device, and the other is the mounting point directory, which means mounting cxlfs to the specified directory. If there are already logs and file data in cxlfs, the corresponding file structure will be generated under the mounting point directory of the host during mounting. The non-data area in this embodiment includes the metadata area, the superblock area, and the log area.

[0039] In this embodiment, the non-data area of the shared memory is mapped through the hidden metadata file (.meta file). Independent views are generated when all hosts are mounted. Multi-host data consistency is achieved through log replay. The user-state program directly operates on the metadata through the.meta file, avoiding frequent switching between the kernel state and the user state and improving the concurrency performance.

[0040] Exemplarily, assume that two hosts (HostA, B) are mounted with cxlfs. For HostA (the master node), format the devdax character device, divide it into a superblock area, a metadata area, a log area, and a data area, mount cxlfs, generate a.meta file under / mnt / cxlfs (example), map the non-data area, and perform log replay. For HostB, mount cxlfs, generate an independent.meta file under / mnt / cxlfs, map the non-data area of the same shared memory, and perform log replay.

[0041] Through the present invention, since the shared memory device is configured as a character device and directly mapped to the user-mode virtual address space, bypassing the kernel page cache and directly reading and writing the physical address of the shared memory, multi-host cache conflicts are fundamentally avoided. When formatting, the shared memory is divided into a superblock area, a metadata area, a log area, and a data area. All hosts perform unified operations through the shared metadata area, avoiding single-machine cache interference. When mounting, a hidden metadata file is created to map the non-data area, and the log entries are scanned to reconstruct the directory file structure, enabling all hosts to generate a directory file structure identical to the shared memory through log replay, solving the data consistency problem of traditional multi-host file systems caused by cache policies, achieving a unified memory view for multi-host sharing, real-time synchronization of operations, and reducing the data access latency.

[0042] It can be understood that the file management method provided by the operating system to the user mode is divided into two levels. Upward, it provides a unified file management interface for users based on VFS, and downward, it processes the file management requests sent by VFS based on the real file system at the mount point. The file management process of cxlfs is also based on this mode. After multi-hosts mount cxlfs, the file management commands issued in the mount point directory are recognized and pre-processed by the kernel VFS layer and forwarded to the processing logic of cxlfs, and finally converted into dax read and write operations of data in the CXL Region (that is, directly accessing the data on the storage device through the dax mode without copying the data into the page cache).

[0043] The following will introduce the file management strategy of cxlfs from the perspective of file management by describing the key operation processes such as file system formatting, mounting, and file operations.

[0044] In an exemplary embodiment, a process of formatting a character device to divide physical memory into a super block, a metadata area, a log area, and a data area includes: obtaining preset configuration parameters; the preset configuration parameters include log area capacity, a maximum number of log entries, and a total number of physical pages; dividing the physical memory into the super block, the metadata area, the log area, and the data area based on the preset configuration parameters and address offset parameters; wherein the process of dividing the physical memory into the super block, the metadata area, the log area, and the data area based on the preset configuration parameters and address offset parameters includes: writing file system information into the super block, the information including a unique identifier of the file system, identity information, a starting address of the metadata area, log area capacity, and a total number of physical pages; calculating address offset parameters of the metadata area, address offset parameters of the log area, and address offset parameters of the data area based on the number of log list entries and the total number of physical pages; initializing a log bitmap and a page bitmap of the metadata area and setting an initial state to an unlocked log lock; pre-allocating a fixed-size log entry list in the log area, with each log entry having the same size; and dividing logical data blocks in the data area according to physical pages.

[0045] In this embodiment, the mmap (memory map) system call is used in user mode to map the devdax file to the virtual memory address of the working process. Based on the passed configuration parameters (log area size, maximum number of log entries, and maximum number of physical pages), the CXL Region is initialized into four areas: superblock, meta, log, and data. Basic cxlfs information is populated into the superblock, and the address offsets of the meta, log, and data areas are calculated based on the number of log list entries and the total number of physical pages, completing the initialization of the relevant data structures.

[0046] In an exemplary embodiment, the process of reading the information of the super block, generating the root directory of the virtual file system based on the information, creating a hidden metadata file under a preset mount point path and mapping it to the non-data area of the physical memory includes: reading the information of the super block, generating a file system context based on the information; creating the root directory of the virtual file system under the preset mount point path, and pointing the private pointer of the index node of the root directory to the super block; creating a hidden metadata file under the mount point directory, and pointing the private pointer of the index node of the hidden metadata file to the non-data area of the shared memory device; the mount point directory is the local directory corresponding to the root directory.

[0047] The mounting of cxlfs in this embodiment is divided into three steps:

[0048] Reference Figure 4 , the first step: kernel state mount system call.

[0049] When any host mounts cxlfs, it first triggers the mount process in the kernel state, performs the exclusive mount actions of the cxlfs file system, and creates a file system context (fs_context) structure for subsequent creation processes; reads the information (such as identity information) of the file system in the superblock area of the CXL Region, and fills it into the file system context; based on the preset mount point path, generates the object relationship and operation method of the root node VFS, and points the private pointer i_private of the root inode to the superblock area; generates a vfsmount (virtual file system mount) structure and incorporates it into the unified management of the kernel. Among them, d_sb represents the pointer from the directory entry to the superblock, s_root represents the pointer of the root directory entry of the superblock, and d_inode represents the pointer of the inode corresponding to the directory entry.

[0050] Refer to Figure 4 , the second step: creation and mapping of the.meta file.

[0051] After the kernel state mount is completed, the VFS object of the mount root node already exists in the local memory of the host. Next, the mapping of user state metadata is completed. After cxlfs is mounted, it will generate a hidden metadata file, namely the.meta file, in the root directory of the mount point, which represents the user state metadata. The.meta file provides a shortcut to access the superblock, metadata, and log area of the CXL Region. The application program of the host can quickly access the formatted data on the CXL Region by mmap mapping this file, so as to better provide fast access and synchronization services for multiple hosts. The process of this step includes creating and keeping the.meta file open, and pointing the private pointer i_private of the inode of the file to the CXLRegion area. Figure 4 In it, fd is the file descriptor.

[0052] In an exemplary embodiment, the process of scanning all log entries in the log area to reconstruct a directory file structure that is globally consistent with the shared memory device in the local memory includes: locating the starting address of the log area through the hidden metadata file, and traversing all log entries starting from the starting address; for each log entry, if the log entry is not marked with an abnormal lock, when the log entry corresponds to a directory log entry, create a corresponding directory in the local memory, when the log entry corresponds to a file log entry, create a file inode, associate the logical data block address, and generate a file node in the directory tree of the virtual file system. If the log entry is marked with an abnormal lock, skip the log entry.

[0053] The last step of the mounting operation is log replay, which aims to map the file and directory relationships recorded in the CXL Region log list and generate a consistent view of the directory file structure in the local memory of the current host. Log replay is based on the.meta file. During replay, the worker process maps the non-data area of the CXL Region, locates the log bitmap and the address offset of the log list according to the size of the superblock area, and starts traversing the directory entries in sequence. During this process, if a directory log entry is encountered, a directory is recreated; if a file log entry is encountered, a file is recreated. The principle of log replay is as Figure 5 shown. It can be seen that there are 4 log entries stored in the current log. Under directory 1 (the first-level directory dir1), there are file 1 and directory 2 (the second-level directory dir2), and there is also file 2 under dir1. These log entries are associated with each other through an indexing mechanism, and the file log entries retain the address offset to the data block. After log replay, the cxlfs mount point view of the current host is re-established and is consistent with that in the CXL Region. It can be understood that the core feature of cxlfs mounting is to generate a.meta metadata file under the current mount point directory to map the non-data area on the CXL Region.

[0054] In an exemplary embodiment, the method for a multi-host shared file system further includes: in response to being a master node or a slave node, performing a file creation operation, a file deletion operation, a file search operation, or a file read / write operation in the file system based on a hidden metadata file.

[0055] In this embodiment, file addition, deletion, and search are the most basic functions of the file system. In the kernel mode, they are jointly assisted by user-mode tools, system calls, VFS layer processing, and cxlfs executing preset methods. Referring to Figure 6 , cxlfs provides basic file operations file_operations, directory operations inode_dir_operations, and other operation methods in the kernel mode, covering all file and directory operations. Since the file and directory structure objects of cxlfs always exist in memory and are only associated with the data blocks of the CXL Region when necessary, there is no other special processing flow in the kernel mode. Therefore, the basic directory operation methods of cxlfs default to reuse the simple auxiliary methods provided by VFS to provide standardized directory processing operations. Most of the basic file operation methods reuse the general interfaces provided by VFS. Cxlfs will cooperate with the relevant operations in the user mode based on these general interfaces to complete the file management process.

[0056] In an exemplary embodiment, the process of performing a file creation operation in a file system includes: when receiving a file creation instruction, creating a temporary file inode; accessing the metadata area based on a hidden metadata file, determining free log bits in the log bitmap of the metadata area, and creating a log entry; determining physical pages in the page bitmap of the metadata area according to the file size, constructing logical data blocks, and writing the address offset parameter and length parameter corresponding to the logical data blocks into the log entry; and pointing the private pointer of the temporary file inode to the logical data blocks.

[0057] In this embodiment, triggered by the cxlfs user-space tool, the creation operation is divided into three stages:

[0058] In the first stage, enter the kernel space and call the creation operation in the directory operation method to create an inode that is active (exists) in memory by default.

[0059] In the second stage, completed by the user-space process. First, based on the virtual address mapped by the.meta file, find free log bits in the log bitmap and create a log entry. Subsequently, according to the size of the file to be created, find a suitable physical page space based on the page bitmap, construct logical data blocks, and store the information (such as address offset parameters and length parameters) of the logical data blocks of the file into the log entry.

[0060] In the third stage, still completed by the user-space process. Based on the ioctl operation, point the i_private pointer of the file inode object to the logical data blocks in the CXL Region. It should be noted that directory creation only creates inodes in memory and log entries in the CXL Region, and performs the association actions between the log entries. Cxlfs does not allocate logical data blocks for directories.

[0061] In an exemplary embodiment, the process of performing a file deletion operation in a file system includes: when receiving a file deletion instruction, deleting the inode of the file to be deleted corresponding to the file deletion instruction in local memory; accessing the non-data area based on a hidden metadata file, and deleting the log entry and logical data blocks of the file to be deleted.

[0062] In this embodiment, the file deletion operation is triggered by the cxlfs user-space tool, and the deletion operation is divided into two stages:

[0063] In the first stage, the user space executes the rm instruction, and finally calls unlink to delete the inode in memory.

[0064] The second stage is completed by the user - mode process. Based on the virtual addresses mapped from the.meta file, the log entries and logical data blocks of the file to be deleted are found. First, the log entries are deleted, and then the logical data blocks are deleted. It can be understood that deleting a log entry only sets the deletion flag in its structure to 1 and synchronously modifies the log bitmap; similarly, deleting a logical data block requires resetting the page bitmap. It should be noted that deleting a directory requires recursive deletion, that is, deleting all files under the directory.

[0065] In an exemplary embodiment, the process of performing a file search operation in a file system includes: accessing the non - data area based on the hidden metadata file, scanning all log entries in the log area; if a log entry is not marked with an abnormal lock, generating a file directory structure in local memory according to the log content; starting from the inode of the root directory based on the virtual file system, parsing the user - input path level by level to locate the file pointer and inode object of the first target file.

[0066] In this embodiment, the file search operation is triggered by the cxlfs user - mode tool, and the search operation is divided into two stages:

[0067] In the first stage, the user - mode performs a log replay action to synchronize the current file system mount view.

[0068] In the second stage, the user - mode performs a search system call, and finally completes the search process via the cxlfs directory operation method.

[0069] In an exemplary embodiment, the process of performing a file read - write operation in a file system includes: obtaining the inode of the second target file based on the user - input file path, and based on the physical address of the data area located by the private pointer of the inode of the second target file, calling the memory direct read - write method in the character device driver to perform a read operation or a write operation on the physical address.

[0070] In this embodiment, the file read - write operation is triggered by the cxlfs user - mode tool, and the file read - write process will be completed by the read - write method of the cxlfs file operation. The read - write method of the cxlfs file operation is a logical encapsulation of the read - write method of the dax device. Based on the dax technology, it directly addresses the corresponding physical address from the i_private of the inode, bypassing the file page cache to ensure read - write performance.

[0071] Regarding file management operations, cxlfs has the following characteristics:

[0072] First, after a file is created on a host, other hosts will not immediately perceive and synchronize it. Only when other hosts trigger a log replay can they see the newly created file.

[0073] Second, when the host deletes a file, it will first delete the file view in the local memory, and other hosts need to update the deleted file view after log replay.

[0074] As a shared file system, how to ensure concurrent security in a multi-host environment is a key issue for cxlfs. Cxlfs implements the consistency of file data based on two strategies of the lock mechanism. The locks in cxlfs can be classified into file locks (log area) and log locks (metadata area) in terms of types. The present invention will be introduced separately in combination with different scenarios.

[0075] In an exemplary embodiment, the log area includes file locks, and the metadata area includes log locks; the method for a multi-host shared file system further includes: in response to being a master node or a slave node, accessing the non-data area based on the hidden metadata file, adding a file lock to the current target file if the access permission of the current target file is obtained, and stopping accessing the current target file if a file lock is detected for the current target file.

[0076] In this embodiment, two fields are reserved in each file log entry structure of cxlfs, namely DIR_L and RW_L, collectively referred to as file locks, which can act on a file structure at the same time. DIR_L is the exception lock of the file, indicating whether the metadata of the current file is being modified by other hosts; RW_L is the read-write lock of the file. The u32 integer RW_L consists of 1 bit access flag bit, 1 bit write lock bit (W), and 30 bit read count variable group (R_count), which are used to maintain mutually exclusive read and write operations among multiple hosts. The structure of the file lock is as Figure 7 shown.

[0077] In the context of multiple access competitions, the host realizes file access through the read, write, or read-write mapping methods provided by the cxlfs user-state tool. Inevitably, read-write competitions of multiple hosts accessing simultaneously will occur. For example, when a host writes to a certain file, if another host reads the file at the same time, the reader will obtain abnormal data of the file; if no host writes to the file, multiple hosts are allowed to read simultaneously to achieve concurrent access. In this scenario, cxlfs provides file read-write locks to ensure concurrent security. Figure 8 describes this scenario. When multiple hosts read a certain file simultaneously, cxlfs will locate the file log entry based on the.meta file and try to access the ACCESS bit ( Figure 8Set the ACCESS bit (denoted as ACC in the Chinese text) to 1 to obtain the operation permission for the read-write lock. After this step is successful, the current host process will attempt to add a read lock to the current file (the read count is incremented). If there is a write lock on the current file, it means the file is being written by another host, so the current process will abandon the read attempt and release the ACCESS flag bit at the same time. If the write lock bit of the current file is 0, the read lock is successfully added, the read count is incremented by one, and the application process of the current host obtains the read access permission.

[0078] When a host attempts to write to a certain file, cxlfs will locate the file log entry based on the.meta file and attempt to set the ACCESS bit to 1 to obtain the operation permission for the read-write lock. After this step is successful, the current host process will attempt to add a write lock to the current file. If the read count of the current file is not 0, it means the file is being read by another host, so the current process will abandon the write attempt and release the ACCESS flag bit at the same time. If the read count of the current file is 0, the write lock is successfully added, and the application process of the current host obtains the write access permission.

[0079] The writing of cxlfs to the physical bits of the CXL Region should ensure atomicity and visibility, which is guaranteed by the CXL3.0 protocol. The ACCESS flag bit is used to ensure the overall atomicity of the read-write lock judgment and the writing operation.

[0080] In the competition scenario of log replay and modification, since the addition and deletion operations of files and directories will change the log list, in this case, if other hosts execute the log replay operation simultaneously, competition will inevitably occur. cxlfs uses the file exception lock DIR_L to ensure the concurrency safety of this scenario, referring to Figure 9 . When the log entry of a file or directory is modified by an addition or deletion action, the host application process will set the exception lock bit of this log entry to 1 to represent that the file is "abnormal", that is, there is a host modifying it. Based on this, if other hosts concurrently execute log replay at this time, cxlfs will not replay the log entries marked with the "exception lock". In this way, cxlfs can ensure the data consistency of complete files among multiple hosts and tolerate a certain degree of temporary inconsistency of "abnormal" files.

[0081] In an exemplary embodiment, the method for a multi-host shared file system further includes: in response to being the master node or the slave node, accessing the non-data area based on the hidden metadata file, performing the operation of applying for a lock object. If the log lock is applied for, add an exception lock and a write lock to the log entry of the current file for the creation operation of the current file.

[0082] The log lock is located in the metadata area of cxlfs, adjacent to the log bitmap, and is used to manage concurrent modifications to the log. The log lock actually acts on the log bitmap. The host that owns this lock will exclusively possess the right to modify the log, and thus exclusively possess the right to add or delete files. The log lock also relies on the cache coherence feature of CXL 3.0 to ensure the visibility of this lock bit in the local caches of different hosts.

[0083] In the scenario where multiple hosts simultaneously create or delete files with the same name, at this time, each host will compete for modifying the log. cxlfs uses the log lock to ensure concurrent security in this scenario. Taking the example of multiple hosts creating files with the same name (the deletion operation is similar), Figure 10 describes the role of the log lock in this scenario. When multiple hosts mounted with cxlfs simultaneously create a file, they will first apply for the log lock from cxlfs respectively. The process of applying for the lock is to copy the lock object into memory and even into the CPU (Central Processing Unit) cache and set it to 1. After the lock object is successfully applied for, the application process will attach an exception lock and a write lock to the current file log entry to ensure the competition of log replay and read-write access, and then continue with the file creation operation. The host that fails to apply for the lock object will enter the "creation busy" state and the process will exit. Based on this mechanism, cxlfs ensures the concurrent security when multiple hosts modify or delete files or directories.

[0084] In the competition between access and deletion, the access of the host application to a certain file will ultimately cause the process to hold the actual pointer to the data area of this file, which will introduce a potential problem. When multiple hosts hold the virtual address of a certain file and are performing read-write access, if this file is deleted by another host through a deletion operation, the data block of this file will be recycled by cxlfs and reallocated to other newly created files; then the application program that is currently accessing will read incorrect file content and may even contaminate the cxlfs data area. This embodiment adopts a lazy deletion method to avoid the competition problem in this scenario. In the file exception lock DIR_L, there is another flag bit representing whether the file has been deleted. Based on this, when cxlfs deletes a file, it will first delete the log entry of the file (set 1 for the deletion position) and modify the bitmap; then judge whether the file is accessed by other hosts according to the read-write lock. If there are accessing hosts for the current file, skip the action of deleting the data block; otherwise, synchronously delete the data block and recycle the relevant physical pages. This process is shown in the appendix Figure 11 By adopting this lazy deletion method, even if the file to be deleted is being used by other hosts, the data block of this file will not be recycled until the last accessing host releases these physical pages.

[0085] In summary, cxlfs implements concurrent security between hosts based on file read-write locks, exception locks, and log locks. Regarding concurrent security, cxlfs has the following characteristics: First, when a host writes to a file, other hosts will fail to read or write the file when attempting to do so through user-space tools; when a host reads a file, other hosts will fail to write to the file when attempting to do so through user-space tools; when multiple hosts read a file simultaneously, the read operation will succeed. Second, when a host deletes a file, other hosts will trigger log replay within a very short period of time and will not be able to access the file being created. Third, when multiple hosts create or delete files with the same name, only one host can perform the create or delete operation at the same time, and the hosts that do not perform the create or delete operation will receive a "busy" notification. Fourth, when a host deletes a file, it will not affect the normal use of other hosts that have obtained the file pointer.

[0086] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation method.

[0087] The embodiment of the present invention also provides a system for a multi-host shared file system. Multiple hosts are connected to a shared memory device and are applicable to any host. The system for the multi-host shared file system includes: a processing module, which is used to, in response to itself being the master node, configure the shared memory device as a character device, map the physical memory corresponding to the character device to the user-space virtual address space, and format the character device to divide the physical memory into a superblock area, a metadata area, a log area, and a data area; a mounting module, which is used to, in response to itself being the master node or a slave node, perform a mounting operation. The mounting operation includes: reading the information in the superblock area, generating the root directory of the virtual file system based on the information, creating a hidden metadata file under the preset mounting point path and mapping it to the non-data area of the physical memory, and scanning all log entries in the log area to reconstruct a directory file structure that is globally consistent with the shared memory device in the local memory.

[0088] In an exemplary embodiment, the process of formatting the character device to divide the physical memory into a superblock area, a metadata area, a log area, and a data area includes: obtaining preset configuration parameters; the preset configuration parameters include the log area capacity, the maximum number of log entries, and the total number of physical pages; dividing the physical memory into a superblock area, a metadata area, a log area, and a data area according to the preset configuration parameters and the address offset parameters.

[0089] In an exemplary embodiment, the process of dividing physical memory into a superblock area, a metadata area, a log area, and a data area according to preset configuration parameters and address offset parameters includes: writing information of the file system into the superblock area, where the information includes the unique identifier of the file system, identity information, the starting address of the metadata area, the capacity of the log area, and the total number of physical pages; calculating the address offset parameter of the metadata area, the address offset parameter of the log area, and the address offset parameter of the data area based on the number of log list items and the total number of physical pages respectively; initializing the log bitmap and page bitmap of the metadata area, and setting the initial state of the log lock to unlocked; pre-allocating a log item list of a fixed size in the log area, where each log item has the same size; and dividing logical data blocks by physical pages in the data area.

[0090] In an exemplary embodiment, the process of reading information from the superblock area, generating the root directory of the virtual file system based on the information, and creating a hidden metadata file and mapping it to the non-data area of the physical memory under a preset mount point path includes: reading the information from the superblock area and generating a file system context based on the information; creating the root directory of the virtual file system under the preset mount point path, and pointing the private pointer of the inode of the root directory to the superblock area; creating a hidden metadata file under the mount point directory, and pointing the private pointer of the inode of the hidden metadata file to the non-data area of the shared memory device; and the mount point directory is the local directory corresponding to the root directory.

[0091] In an exemplary embodiment, the process of scanning all log items in the log area to reconstruct a directory file structure globally consistent with the shared memory device in local memory includes: locating the starting address of the log area through the hidden metadata file, and traversing all log items starting from the starting address; for each log item, if the log item is not marked with an exception lock, when the log item corresponds to a directory log item, creating a corresponding directory in local memory, when the log item corresponds to a file log item, creating a file inode, associating the logical data block address, and generating a file node in the directory tree of the virtual file system, and if the log item is marked with an exception lock, skipping the log item.

[0092] In an exemplary embodiment, the system of the multi-host shared file system is further configured to: in response to being the master node or the slave node, perform a file creation operation, a file deletion operation, a file search operation, or a file read / write operation in the file system based on the hidden metadata file.

[0093] In an exemplary embodiment, the process of performing a file creation operation in a file system includes: when a file creation instruction is received, creating a temporary file inode; accessing the metadata area based on a hidden metadata file, determining free log bits in the log bitmap of the metadata area, and creating a log entry; determining physical pages in the page bitmap of the metadata area according to the file size, constructing logical data blocks, and writing the logical data blocks into the log entry; and pointing the private pointer of the temporary file inode to the logical data blocks.

[0094] In an exemplary embodiment, the process of performing a file deletion operation in a file system includes: when a file deletion instruction is received, deleting the inode of the file to be deleted corresponding to the file deletion instruction in local memory; accessing the non-data area based on a hidden metadata file, and deleting the log entry and logical data blocks of the file to be deleted.

[0095] In an exemplary embodiment, the process of performing a file search operation in a file system includes: accessing the non-data area based on a hidden metadata file, and scanning all log entries in the log area; if the log entry is not marked with an exception lock, generating a directory tree in local memory according to the log content; starting from the inode of the root directory based on the virtual file system, parsing the user input path level by level, and locating the inode of the first target file and the address of the logical data blocks.

[0096] In an exemplary embodiment, the process of performing a file read / write operation in a file system includes: in response to receiving a file read instruction or a file write instruction, locating the physical address of the data area through the private pointer of the inode of the target file corresponding to the file read instruction or the file write instruction, and performing a read operation or a write operation based on the physical address.

[0097] In an exemplary embodiment, the log area includes file locks, and the metadata area includes log locks; the system of the multi-host shared file system is further configured to: in response to being the master node or the slave node, accessing the non-data area based on a hidden metadata file, adding a file lock to the current target file if the access permission of the current target file is obtained, and stopping accessing the current target file if a file lock of the current target file is detected.

[0098] In an exemplary embodiment, the system of the multi-host shared file system is further configured to: in response to being the master node or the slave node, accessing the non-data area based on a hidden metadata file, performing a lock object application operation, and adding an exception lock and a write lock to the log entry of the current file if a log lock is applied, so as to perform the creation operation of the current file.

[0099] For the description of the features in the embodiments corresponding to the system of the multi-host shared file system, reference may be made to the relevant description of the embodiments corresponding to the method of the multi-host shared file system, which will not be elaborated here one by one.

[0100] An embodiment of the present invention further provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any of the above method embodiments of the multi-host shared file system.

[0101] An embodiment of the present invention further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps in any of the above method embodiments of the multi-host shared file system when running.

[0102] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: various media such as USB flash drives, read-only memories (ROM for short), random access memories (RAM for short), mobile hard disks, magnetic disks, or optical discs that can store computer programs.

[0103] An embodiment of the present invention further provides a computer program product. The above computer program product includes a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments of the multi-host shared file system are implemented.

[0104] An embodiment of the present invention further provides another computer program product, including a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments of the multi-host shared file system are implemented.

[0105] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described according to their functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0106] The above has introduced in detail a method, product, device and storage medium of a multi-host shared file system provided by the present invention. Specific examples are used in this article to elaborate on the principle and implementation manner of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the protection scope of the claims of the present invention.

Claims

1. A method for a multi-host shared file system, characterized in that Multiple hosts are connected to a shared memory device. The method for the multiple hosts to share a file system, which is applied to any of the hosts, includes: In response to itself being the master node, configuring the shared memory device as a character device, mapping the physical memory corresponding to the character device to the user-mode virtual address space, and formatting the character device to divide the physical memory into a superblock area, a metadata area, a log area, and a data area; In response to itself being the master node or a slave node, performing a mount operation, where the mount operation includes: reading the information in the superblock area, generating the root directory of the virtual file system based on the information, creating a hidden metadata file under the preset mount point path and mapping it to the non-data area of the physical memory, and scanning all log entries in the log area to reconstruct a directory file structure that is globally consistent with the shared memory device in the local memory; The process of formatting the character device to divide the physical memory into a superblock area, a metadata area, a log area, and a data area includes: Obtaining preset configuration parameters; the preset configuration parameters include the log area capacity, the maximum number of log entries, and the total number of physical pages; Writing the information of the file system into the superblock area, where the information includes the unique identifier of the file system, identity information, the starting address of the metadata area, the log area capacity, and the total number of physical pages; Calculating the address offset parameters of the metadata area, the address offset parameters of the log area, and the address offset parameters of the data area based on the number of log list entries and the total number of physical pages respectively; Initializing the log bitmap and page bitmap of the metadata area and setting the initial state of the log lock to unlocked; Pre-allocating a log entry list of a fixed size in the log area, where each log entry has the same size; Dividing the logical data blocks by physical pages in the data area.

2. The method of the multi-host shared file system according to claim 1, wherein The process of reading the information in the superblock area, generating the root directory of the virtual file system based on the information, creating a hidden metadata file under the preset mount point path and mapping it to the non-data area of the physical memory includes: Reading the information in the superblock area and generating a file system context based on the information; Creating the root directory and root inode of the virtual file system based on the preset mount point path and pointing the private pointer of the root inode to the superblock area; Creating a hidden metadata file under the preset mount point path and pointing the private pointer of the inode of the hidden metadata file to the non-data area of the shared memory device.

3. The method of the multi-host shared file system according to claim 2, wherein The process of scanning all log entries in the log area to reconstruct a directory file structure that is globally consistent with the shared memory device in the local memory includes: Locating the starting address of the log area through the hidden metadata file and traversing all log entries starting from the starting address; For each log entry, if the log entry is not marked with an exception lock, when the log entry corresponds to a directory log entry, creating a corresponding directory in the local memory, when the log entry corresponds to a file log entry, creating a file inode, associating the logical data block address, and generating a file node in the directory tree of the virtual file system, and if the log entry is marked with the exception lock, skipping the log entry.

4. The method of the multi-host shared file system according to claim 2, wherein The method for the multi-host shared file system further includes: In response to itself being the master node or the slave node, based on the hidden metadata file, perform a file creation operation, a file deletion operation, a file search operation, or a file read / write operation in the file system.

5. The method of the multi-host shared file system according to claim 4, wherein, The process of performing a file creation operation in the file system includes: When receiving a file creation instruction, create a temporary file inode. Access the metadata area based on the hidden metadata file, determine free log bits in the log bitmap of the metadata area, and create a log entry. Determine physical pages in the page bitmap of the metadata area according to the file size, construct logical data blocks, and write the address offset parameter and length parameter corresponding to the logical data blocks into the log entry. Point the private pointer of the temporary file inode to the logical data block.

6. The method of the multi-host shared file system according to claim 4, wherein The process of performing a file deletion operation in the file system includes: When receiving a file deletion instruction, delete the inode of the file to be deleted corresponding to the file deletion instruction in the local memory. Access the non-data area based on the hidden metadata file, and delete the log entry and logical data block of the file to be deleted.

7. The method of the multi-host shared file system according to claim 4, wherein The process of performing a file search operation in the file system includes: Access the non-data area based on the hidden metadata file, and scan all log entries in the log area. If the log entry is not marked with an abnormal lock, generate a file directory structure in the local memory according to the log content. Based on the virtual file system, start from the inode of the root directory, parse the user input path level by level, and locate the file pointer and inode object of the first target file.

8. The method of the multi-host shared file system according to claim 4, wherein The process of performing a file read / write operation in the file system includes: Obtain the inode of the second target file based on the user input file path, and based on the physical address of the data area located by the private pointer of the inode of the second target file, call the memory direct read / write method in the character device driver to perform a read operation or a write operation on the physical address.

9. The method of the multi-host shared file system according to any one of claims 1-8, characterized in that The log area includes file locks, and the metadata area includes log locks. The method for the multi-host shared file system further includes: In response to itself being the master node or the slave node, access the non-data area based on the hidden metadata file. If the access permission for the current target file is obtained, add a file lock to the current target file. If it is detected that the current target file has the file lock, stop accessing the current target file.

10. The method of the multi-host shared file system according to claim 9, wherein The method for the multi-host shared file system further includes: In response to itself being the master node or the slave node, access the non-data area based on the hidden metadata file, perform a lock object application operation. If the log lock is applied, add an abnormal lock and a write lock to the log entry of the current file for the creation operation of the current file.

11. A computer program product, characterized in that, It includes a computer program / instructions, and when the computer program / instructions are executed by a processor, the steps of the method for the multi-host shared file system according to any one of claims 1 to 10 are implemented.

12. An electronic device, characterized in that, It includes: A memory for storing a computer program; A processor for implementing the steps of the method for the multi-host shared file system according to any one of claims 1 to 10 when executing the computer program.

13. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the method for the multi-host shared file system according to any one of claims 1 to 10 are implemented.

Images