A file access system and method using a storage device

Abstract

This invention discloses a file access system and method utilizing a storage device, belonging to the field of file access. The system includes a host end and a storage device end. The host end includes a user library U-lib and a kernel driver K-lib. A controller core in the storage device end includes a device firmware runtime Firm-RT. The device firmware runtime Firm-RT creates file system partitions, setting an attribute flag for each file system within each partition. When a file system processing call is needed, the corresponding file system is loaded onto the device firmware runtime Firm-RT based on the attribute flag, thus separating the file system from the storage device. The file system is dynamically loaded onto the Firm-RT during use, and different file systems can be selected according to user needs, achieving replaceable functionality and making the file system usage scenarios more flexible.

Description

Technical Field

[0001] This invention relates to the field of file access, and in particular to a file access system and method utilizing a storage device. Background Technology

[0002] With the advent of high-speed storage devices such as SSDs and SCMs, computer storage systems have undergone tremendous changes in the past decade, with storage access latency advancing from the millisecond level to the microsecond level. While these new storage devices have altered the storage hierarchy of computer systems, the memory wall remains a performance bottleneck due to the increase in data-intensive workloads and the slowdown of Moore's Law and Dennard's Law. To reduce the overhead of data movement, Near Data Processing (NDP) has been proposed and, with the development of 2.5D and 3D stacking, is emerging as a viable and promising solution.

[0003] Due to the significant increase in memory bandwidth and the rapid decrease in latency, software overhead has gradually become a performance bottleneck in the storage path. In order to fully explore the potential of storage systems, the storage stack has been modified. As the most important part of the storage stack software, the file system should be redesigned to reduce software overhead, especially the involvement of the operating system kernel in the data path. Currently, there are many studies discussing the possibilities of file system location, which can be divided into three categories according to location: (1) Kernel-FS, (2) Userspace-FS, and (3) Firmware-FS. Many typical file systems are Kernel-FS, including Ext4, XFS, etc.; Userspace-FS is mainly for bypassing the kernel, and typical examples are Aerie and Strata; Firm-FS offloads part or all of the file system work to the storage device firmware, and examples are DevFS and CrossFS.

[0004] Traditional file systems reside in the kernel because they need to implement integrity guarantees and access control to ensure data security; however, accessing storage requires entering the kernel, incurring overhead. User file systems provide the file system as a user-space library, managing and updating data in user space without entering the kernel, thus improving performance, but also introducing security issues. Firmware file systems, while combining the advantages of both, sacrifice flexibility, only suitable for specific scenarios and unable to meet all needs. Furthermore, with the increasing heterogeneity of computer systems, file access control is becoming increasingly complex, requiring changes to file access modes to better meet user needs. Summary of the Invention

[0005] The purpose of this invention is to provide a file access system and method utilizing storage devices, which makes the use of file systems more flexible.

[0006] To achieve the above objectives, the present invention provides the following solution:

[0007] A file access system utilizing a storage device includes: a host end and a storage device end;

[0008] The host side includes the user library U-lib and the kernel driver K-lib; a controller core on the storage device side includes a device firmware runtime Firm-RT.

[0009] A device firmware runtime Firm-RT is used to create file system partitions, and an attribute flag bit is set for each file system in the file system partition;

[0010] The user library U-lib is used to receive file system calls generated by the APP through the POSIX interface and check whether the cache is hit. If the cache is not hit, the file system call is packaged into an extended NVMe protocol command and passed to the corresponding device firmware runtime Firm-RT based on the NVMe multi-queue mechanism.

[0011] The kernel driver K-lib is used to generate keys and shares the keys with the device firmware runtime Firm-RT.

[0012] Upon receiving the extended NVMe protocol command, the device firmware runtime Firm-RT checks the validity of the extended NVMe protocol command based on the key. After verifying the validity of the extended NVMe protocol command, it determines the attribute flag bit based on the file operation content in the extended NVMe protocol command, loads the file system corresponding to the determined attribute flag bit into the device firmware runtime Firm-RT, and then arranges the data blocks in the extended NVMe protocol command on the storage device through the file system.

[0013] A file access method utilizing a storage device, the file access method being applied to the aforementioned file access system utilizing a storage device, the file access method comprising:

[0014] When an APP generates a file system call operation, it passes the file system call request to the user library U-lib through the POSIX interface. The user library U-lib checks whether the cache is hit.

[0015] If a cache miss occurs, the file system call request is packaged into an extended NVMe protocol command and passed to the corresponding device firmware runtime Firm-RT based on the NVMe multi-queue mechanism.

[0016] During device firmware runtime, Firm-RT creates file system partitions and sets an attribute flag for each file system;

[0017] Upon receiving an extended NVMe protocol command, the device firmware runtime Firm-RT checks the validity of the extended NVMe protocol command;

[0018] After verifying the validity of the extended NVMe protocol commands, the attribute flags are determined based on the file operation content in the extended NVMe protocol commands, and the file system corresponding to the determined attribute flags is loaded into the device firmware runtime Firm-RT.

[0019] The loaded file system processes file system calls to arrange data blocks in the extended NVMe protocol commands on the storage device.

[0020] According to specific embodiments provided by the present invention, the present invention discloses the following technical effects:

[0021] This invention discloses a file access system and method using a storage device. During device firmware runtime, Firm-RT creates a file system partition. In the file system partition, an attribute flag is set for each file system. When file system processing is required, the corresponding file system is loaded onto the device firmware runtime Firm-RT according to the attribute flag, thus separating the file system from the storage device. The file system is dynamically loaded onto Firm-RT during use. At the same time, different file systems can be selected according to user needs, realizing a replaceable function and making the use scenarios of the file system more flexible. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A framework diagram of a file access system utilizing a storage device is provided as an embodiment of the present invention;

[0024] Figure 2 This is a schematic diagram of a multi-queue mechanism based on NVMe provided in an embodiment of the present invention;

[0025] Figure 3 This is a schematic diagram of a file system partition provided in an embodiment of the present invention;

[0026] Figure 4 A flowchart illustrating a file access method using a storage device, as provided in an embodiment of the present invention;

[0027] Figure 5 This is a schematic diagram of a file access method using a storage device provided in an embodiment of the present invention. Detailed Implementation

[0028] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0029] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] like Figure 1 As shown, this embodiment of the invention provides a file access system utilizing a storage device, including a host end and a storage device end.

[0031] The host side includes the user library U-lib and the kernel driver K-lib; the storage device side has a controller core that includes a device firmware runtime Firm-RT. The device firmware runtime Firm-RT is used to create file system partitions, setting an attribute flag for each file system within those partitions.

[0032] The user library U-lib is used to receive file system calls generated by the APP through the POSIX interface and check whether the cache is hit. If the cache is not hit, the file system call is packaged into an extended NVMe protocol command and passed to the corresponding device firmware runtime Firm-RT based on the NVMe multi-queue mechanism.

[0033] The kernel driver K-lib is used to generate keys and shares keys with the device firmware runtime Firm-RT.

[0034] Upon receiving the extended NVMe protocol command, the device firmware runtime Firm-RT checks the validity of the extended NVMe protocol command based on the key. After verifying the validity of the extended NVMe protocol command, it determines the attribute flag bit based on the file operation content in the extended NVMe protocol command, loads the file system corresponding to the determined attribute flag bit into the device firmware runtime Firm-RT, and then arranges the data blocks in the extended NVMe protocol command on the storage device through the file system.

[0035] The specific functions of the user library U-lib, the kernel driver K-lib, and the device firmware runtime Firm-RT are as follows:

[0036] The user library U-lib is used to access the internal file system. It is provided as a dynamic link library and its main function is to expose the POSIX interface to user applications and manage the connection with the device.

[0037] The kernel driver K-lib is a kernel module that provides reliability for control plane operations. Its tasks include resource allocation and permission checks.

[0038] The device firmware runtime Firm-RT provides basic hardware and software support, enabling file systems to run on storage devices. In addition, to serve the file system, Firm-RT communicates with U-lib in the data plane and with K-lib in the control plane.

[0039] Figure 1 In this context, `pread` is a function used to atomically read data from a file with an offset. User Space refers to user space, Kernel Space to kernel space, NVMe-based Queue Protocol to NVMe-based multi-queue mechanism, and FS to file system.

[0040] Specifically, to enable file transfer operations, the NVMe command list is extended in the queuing protocol between the host and storage devices, allowing the extended queuing protocol to include POSIX I / O interfaces. At the same time, the normal data access mode of NVMe is retained to ensure normal disk access in the event of system failure.

[0041] ① When a process containing file system calls passes from U-lib to Firm-RT, the multi-queue protocol kicks in. Each process from U-lib creates a queue pair equal to the number of cores on the storage device controller.

[0042] ② Each queue pair is bound to a controller core on the storage device side, so a process can assign any file operation to a specific controller core, such as... Figure 2 As shown. Figure 2 In this context, "Thread" refers to a thread, and "Core" refers to the controller core.

[0043] At the same time, each user thread has its own dedicated queue pair to avoid queue contention on the host side.

[0044] ③ When file operations in a process are transmitted to the device's Firm-RT by U-lib, U-lib controls which core of the device's controller the file operation should be dispatched to. For example, read-intensive applications can issue read operations to all kernels using a round-robin strategy. For write-intensive applications, different threads can send write operations to the same file to the same controller core to reduce lock contention between controller cores.

[0045] Since file operations are processed on the storage device side, and the storage device may have a multi-core controller, this invention makes full use of the parallelism of the storage device controller kernel while minimizing potential conflicts in concurrent file access.

[0046] Each controller core creates a file system partition for each file operation; there can be one or more file system partitions. All binary files used are stored in a specific partition, and each file system within this partition can be indexed by a label. Multiple partitions are serially linked to store data.

[0047] like Figure 3 As shown, a GUID partition table (GPT) is used to organize partitions, which contains some management data, such as the partition start position (First LBA), the end position (Last LBA), and attribute flags bits.

[0048] GPT organizes partitions (Partition N), which are the data of the GPT access management partition, including the partition start position (First LBA), end position (Last LBA), and attribute flags. Partition N refers to N partitions. Partition i stores the binary files used when the i-th file system was created. Its position can be indicated by the First LBA and Last LBA in GPT. Multiple file systems are stored in PartitionFS as an array, with the attribute flags in GPT pointing to the i-th file system.

[0049] During formatting, each user-created partition is associated with a file system. If the file system is not already present, it will be added to that file system partition. To indicate the relationship between user-created partitions and their file systems, attribute flags are set in GPT to point to the file system. This means that GPT has a pointer to the file system, allowing different file systems to be provided for different partitions—in other words, replaceable file systems. Meanwhile, GPT and partitions can still be used with typical kernel file systems.

[0050] A partition is set up to store multiple file systems, which are managed by the partition table GPT (GUID partition table). The partition and file system are linked through pointers and indexes to realize the function of a replaceable file system; the multi-queue mechanism supports concurrent file access and gives full play to the parallelism of multi-core.

[0051] The process designed in this invention is divided into two main modules: the data plane and the control plane. The control plane is responsible for maintaining the security and reliability of the system and providing necessary support for the normal operation of the data plane.

[0052] The host-side control plane operations ensure security and reliability. U-lib, a user-space driver for NVMe storage device communication, needs to set up VFIO and manage DMA memory mappings to enable direct access to the file system from user space, and also allocate regions for caching. These operations involve the kernel, but only need to run once during device initialization, so there is no performance penalty during normal file access. The device-side control plane helps manage the file system and handles other management operations.

[0053] This invention adopts the idea of ​​near-memory computing (NDP) and uses a multi-queue mechanism to resolve concurrent access conflicts. While ensuring security, it provides a flexible and alternative file system solution and supports direct I / O for heterogeneous computing, while the CPU-side operating system kernel does not participate in data plane access.

[0054] This invention achieves performance several times that of traditional kernel-level file systems when users are reading and writing, thanks to its kernel bypass and near-data file system design.

[0055] In concurrent read / write scenarios, the multi-queue module design allows user applications to control the core of file operations, maximizing the utilization of the controller core and reducing lock contention. This results in more orderly access to the same file, thus outperforming traditional Ext4 systems. In short, the multi-queue mechanism improves concurrency.

[0056] This invention separates the file system from the storage device, allowing the file system to be dynamically loaded onto Firm-RT during use. Different file systems can be selected according to user needs, achieving replaceable functionality and greater flexibility and efficiency—a feature sacrificed by conventional Firm-FS to ensure security. It supports replaceable file systems while ensuring reliability and compatibility. Furthermore, this invention can unlock the potential of new storage devices, aligning with current development trends.

[0057] like Figure 4 As shown, this embodiment of the invention also provides a file access method using a storage device. The file access method is applied to the aforementioned file access system using a storage device, and includes:

[0058] Step 1: When the APP generates a file system call operation, it passes the file system call request to the user library U-lib through the POSIX interface. The user library U-lib checks whether the cache is hit.

[0059] Step 2: If the cache misses, the file system call request is packaged into an extended NVMe protocol command and passed to the corresponding device firmware runtime Firm-RT based on the NVMe multi-queue mechanism.

[0060] Among them, the NVMe-based multi-queue mechanism is passed to the corresponding device firmware runtime Firm-RT, specifically including:

[0061] For each extended NVMe protocol command from the user library U-lib, a queue pair is created; where the number of queue pairs is equal to the number of cores of the storage device controller;

[0062] Each queue pair in the queue pair is bound to a core controller on the storage device side;

[0063] The NVMe protocol commands extended by the user library U-lib are assigned to the corresponding device firmware runtime Firm-RT.

[0064] like Figure 5 As shown, if a cache hit occurs, the data is retrieved from the cache.

[0065] Step 3: During device firmware runtime, Firm-RT creates file system partitions and sets an attribute flag for each file system.

[0066] Step 4: The device firmware that receives the extended NVMe protocol command runs Firm-RT to check the validity of the extended NVMe protocol command.

[0067] Step 5: After verifying the validity of the extended NVMe protocol command, determine the attribute flags based on the file operation content in the extended NVMe protocol command, and load the file system corresponding to the determined attribute flags into the device firmware runtime Firm-RT.

[0068] See Figure 5 If the verification extended NVMe protocol command is invalid, the request is rejected.

[0069] Step 6: Loading File System Processing File system calls arrange data blocks in the extended NVMe protocol commands on the storage device.

[0070] The specific implementation process is as follows:

[0071] The loaded file system handles file system calls and, together with the flash translation layer (FTL) or hardware instruments, arranges data blocks in the extended NVMe protocol commands on the storage device.

[0072] Existing file systems run in kernel mode. When the kernel calls the file system, a context switch is required to switch to kernel mode. However, this invention eliminates the context switch by setting the file system to run on the storage device, thus effectively improving performance.

[0073] This invention provides a file access method that is both secure and highly efficient and flexible, utilizing a novel storage device. It addresses the shortcomings of kernel file systems, user file systems, and firmware file systems, primarily by effectively improving performance by eliminating context switching. It supports replaceable file systems while ensuring reliability and compatibility, making the use of this file system more flexible. Furthermore, it employs a multi-queue mechanism to improve concurrency.

[0074] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. The methods disclosed in the embodiments are described simply because they correspond to the systems disclosed in the embodiments; relevant details can be found in the method section.

[0075] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A file access system utilizing a storage device, characterized by, include: Host and storage device; The host side includes the user library U-lib and the kernel driver K-lib; a controller core on the storage device side includes a device firmware runtime Firm-RT. A device firmware runtime Firm-RT is used to create file system partitions, and an attribute flag bit is set for each file system in the file system partition; The user library U-lib is used to receive file system calls generated by the APP through the POSIX interface and check whether the cache is hit. If the cache is not hit, the file system call is packaged into an extended NVMe protocol command and passed to the corresponding device firmware runtime Firm-RT based on the NVMe multi-queue mechanism. The kernel driver K-lib is used to generate keys and shares the keys with the device firmware runtime Firm-RT. Upon receiving the extended NVMe protocol command, the device firmware runtime Firm-RT checks the validity of the extended NVMe protocol command based on the key. After verifying the validity of the extended NVMe protocol command, it determines the attribute flag bit based on the file operation content in the extended NVMe protocol command, and dynamically loads the file system corresponding to the determined attribute flag bit onto the device firmware runtime Firm-RT, thereby separating the file system from the storage device. At the same time, different file systems can be selected according to user needs, and then the data blocks in the extended NVMe protocol command are arranged on the storage device through the file system.

2. The file access system using a storage device according to claim 1, wherein, The NVMe command list has been extended in the queuing protocol between the host and storage devices to include POSIX I / O interfaces.

3. The file access system utilizing a storage device according to claim 1, characterized in that, A file system partition includes a start position, an end position, and attribute flags; The number of file system partitions can be one or more; when there are multiple file system partitions, they are connected serially.

4. The file access system using a storage device according to Claim 1, characterized by, During device firmware runtime, Firm-RT is also used to create a file partition for storing binary files corresponding to the file system.

5. A file access method using a storage device, characterized by, The file access method is applied to a file access system utilizing a storage device as described in any one of claims 1-4, and the file access method includes: When an APP generates a file system call operation, it passes the file system call request to the user library U-lib through the POSIX interface. The user library U-lib checks whether the cache is hit. If a cache miss occurs, the file system call request is packaged into an extended NVMe protocol command and passed to the corresponding device firmware runtime Firm-RT based on the NVMe multi-queue mechanism. During device firmware runtime, Firm-RT creates file system partitions and sets an attribute flag for each file system; Upon receiving an extended NVMe protocol command, the device firmware runtime Firm-RT checks the validity of the extended NVMe protocol command; After verifying the validity of the extended NVMe protocol commands, the attribute flags are determined based on the file operation content in the extended NVMe protocol commands, and the file system corresponding to the determined attribute flags is loaded into the device firmware runtime Firm-RT. The loaded file system processes file system calls to arrange data blocks in the extended NVMe protocol commands on the storage device.

6. The file access method using a storage device according to claim 5, wherein, Based on the NVMe multi-queue mechanism, the firmware is passed to the corresponding device firmware runtime Firm-RT, specifically including: For each extended NVMe protocol command from the user library U-lib, a queue pair is created; where the number of queue pairs is equal to the number of cores of the storage device controller; Each queue pair in the queue pair is bound to a core controller on the storage device side; The NVMe protocol commands extended by the user library U-lib are assigned to the corresponding device firmware runtime Firm-RT.

7. The file access method using a storage device according to Claim 5, wherein, The loaded file system handles file system calls, arranging data blocks from extended NVMe protocol commands onto the storage device, specifically including: The loaded file system handles file system calls and, together with the flash translation layer (FTL) or hardware instruments, arranges data blocks in the extended NVMe protocol commands on the storage device.

Images