Solid state drive and data access acceleration method thereof

Abstract

This application relates to information storage technology and discloses a solid-state drive (SSD) and a method for accelerating data access thereto. The method includes establishing a mapping relationship between an application identifier and a storage subspace within the SSD, where the application identifier uniquely identifies one or a group of applications on a host; the SSD receives a write command from the host, the write command including the application identifier and data to be written; the SSD determines the target storage subspace to be written to based on the mapping relationship and the application identifier in the write command; and the SSD writes the data to be written to the target storage subspace. This method can significantly improve the write and read performance of the SSD.

Description

[0001] Cross-reference to related applications

[0002] This patent application claims the benefit and priority of U.S. Provisional Application No. 63 / 682,147, filed August 12, 2024, the contents of which are incorporated herein by reference in their entirety for all purposes. Technical Field

[0003] This application relates to the field of storage technology, and in particular to data access acceleration technology for solid-state drives. Background Technology

[0004] This section is intended to provide background or context for understanding the implementation of this application and is for reference only. It should not be construed as an admission by the applicant that this section pertains to prior art that was disclosed before the filing date of this application.

[0005] With the rapid development of computer technology, solid-state drives (SSDs), as flash memory-based storage devices, have been widely used in personal computers and servers. SSDs primarily use NAND flash memory as their storage medium. Compared to traditional hard disk drives (HDDs), SSDs offer higher read / write speeds, lower power consumption, and better shock resistance, significantly improving data access efficiency.

[0006] In SSD data access, the Non-Volatile Memory Express (NVMe) protocol is widely used for communication between the host and the SSD. This protocol supports multi-queue parallel processing, fully utilizing the bandwidth of the PCIe interface to achieve efficient data transfer. However, SSD performance varies significantly under different access modes. In sequential access mode, data is read and written continuously, fully utilizing the characteristics of NAND flash memory and providing high throughput. In contrast, random access mode involves non-contiguous address operations, causing NAND flash memory to perform frequent block erase and garbage collection operations, thereby increasing write amplification and reducing overall performance.

[0007] In existing technologies, data access optimization for SSDs primarily mitigates the problems caused by random access through caching mechanisms, prefetching strategies, or internal scheduling algorithms. For example, some SSD controllers temporarily buffer randomly written data in DRAM and then convert it into sequential writes in batches to reduce garbage collection overhead. Although these methods improve performance to some extent, random access, especially mixed input / output (I / O) requests from multiple applications, still leads to high latency and unstable response times.

[0008] However, in existing technologies, when SSDs process random I / O requests, they are unable to effectively distinguish data streams from different sources, which easily leads to storage space fragmentation, further exacerbating performance bottlenecks and latency issues. Summary of the Invention

[0009] The purpose of this application is to provide a solid-state drive and a method for accelerating data access thereto, which can significantly improve the write and read performance of the solid-state drive.

[0010] This application discloses a method for accelerating solid-state drive (SSD) data access. The method establishes a mapping relationship between application identifiers and storage subspaces within the SSD, where the application identifier uniquely identifies one or a group of applications on the host. The SSD receives a write command from the host, which includes the application identifier and the data to be written. Based on the mapping relationship and the application identifier in the write command, the SSD determines the target storage subspace to be written to. The SSD writes the data to be written to the target storage subspace, wherein the starting position of this write operation is physically contiguous with the ending position of the last written data in the target storage subspace. This method enables application-level contiguous physical address storage, significantly improving the write and read performance of the SSD. Specifically, this contiguous storage reduces addressing overhead caused by fragmentation, lowers latency, and increases data throughput. Especially in high-load application scenarios, it effectively avoids the performance bottleneck caused by traditional random access storage. It also optimizes the flash memory management of the SSD, extends hardware lifespan, and provides basic support for subsequent batch reads, ultimately achieving overall data access acceleration.

[0011] Furthermore, by receiving a read command containing an application identifier, determining the target storage subspace based on the mapping, and reading all data based on the identifier and returning it to the host, the reading process can be simplified, enabling efficient batch data retrieval. This reduces the number of interactions between the host and the solid-state drive, improving system response speed. When applying this reading method to AI training, a single read command can read all the data in the target storage subspace at once, avoiding the overhead of multiple read commands and significantly improving reading efficiency.

[0012] Furthermore, by dividing the application identifier into a first part and a second part, and dividing the solid-state drive's storage subspace into a first-level and a second-level subspace, the target first-level storage subspace is determined based on the first part, and the target second-level storage subspace is further determined based on the second part. This enables tiered and refined storage management, thereby improving the efficiency of storage resource allocation and the isolation of applications.

[0013] Furthermore, by pre-allocating an initial storage subspace of a preset size for each application identifier and determining the remaining capacity during writing, and dynamically expanding the capacity until it is sufficient before writing data, the system can flexibly adapt to the data growth needs of different applications, thereby avoiding write failures or fragmentation and improving storage utilization and system reliability.

[0014] Furthermore, by periodically checking the physical address continuity of the storage subspace and rescheduling and migrating data for discontinuous parts, the continuity of the storage subspace can be maintained, thereby continuously optimizing data access performance and reducing the potential impact of fragmentation.

[0015] Furthermore, by determining the target primary storage subspace based on the first part of the application identifier, identifying the access mode type (e.g., sequential or random) of the data to be written, and further determining the target secondary storage subspace accordingly, storage can be optimized for different access modes, thereby improving the high throughput of sequential data and the low latency processing capability of random data.

[0016] Furthermore, by defining data with sequential access patterns, including video streams, logs, or large file data, and data with random access patterns, including indexes, metadata, or structured record data, more precise access pattern classification can be achieved. This provides targeted guidance for subsequent storage and retrieval strategies, thereby improving the overall efficiency of data processing.

[0017] Furthermore, by adopting appropriate pre-read strategies (such as large-block pre-read in sequential mode, small-block or no pre-read in random mode) when reading data from the target storage subspace, cache utilization and pre-loading can be optimized, thereby significantly reducing read latency and improving user experience.

[0018] Furthermore, by optimizing the writing method to achieve faster speeds before writing the data to the target storage subspace, write performance can be further enhanced, thereby reducing overall I / O latency and improving the responsiveness of the solid-state drive.

[0019] Furthermore, by using the NVMe protocol to interact with the host and designing the write command as an extended write command that conforms to the NVMe protocol, a standardized and efficient communication interface can be achieved, thereby ensuring compatibility with the existing hardware ecosystem and improving the reliability and speed of data transmission. Attached Figure Description

[0020] Figure 1 This is a schematic flowchart of a solid-state drive data access acceleration method according to an embodiment of this application. Detailed Implementation

[0021] In the following description, many technical details are presented to help the reader better understand this application. However, those skilled in the art will understand that the technical solutions claimed in this application can be implemented even without these technical details and various variations and modifications based on the following embodiments.

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0023] The first embodiment of this application relates to a method for accelerating data access to a solid-state drive, the process of which is as follows: Figure 1 As shown, the method includes the following steps:

[0024] In step 101, a mapping relationship is established between application identifiers and storage subspaces within the solid-state drive (SSD). The application identifier uniquely identifies one or a group of applications on the host. The application identifier can be a unique number or string generated by the host. Preferably, in some embodiments, at least one storage subspace is physically address-contiguous. A storage subspace may include multiple storage cells (such as flash pages or blocks). "Physically address-contiguous within a storage subspace" means that the physical addresses of the multiple storage cells within the storage subspace are consecutive and sequentially adjacent in the NAND flash memory medium, without address gaps or fragmentation. In some embodiments, a storage subspace may include multiple storage regions, each containing multiple physically address-contiguous storage cells.

[0025] In step 102, the solid-state drive receives a write command from the host, which includes an application identifier and data to be written.

[0026] Then proceed to step 103, where the solid-state drive determines the target storage subspace to be written to based on the mapping relationship and the application identifier in the write command.

[0027] Next, in step 104, the solid-state drive writes the data to be written to the target storage subspace. The starting position of this write operation is physically contiguous with the ending position of the last written data in the target storage subspace. If there is no data in the target storage subspace, writing begins from the starting physical address of the target storage subspace.

[0028] Step 101 above is a pre-setup step, and steps 102-104 are processing steps performed after receiving the write command.

[0029] The above method can be applied to all storage subspaces or only to a portion of them. It can be applied to all write commands or only to certain write commands (e.g., write commands with a specific application identifier or write commands that meet other conditions).

[0030] Solid-state drives (SSDs) allocate independent storage subspaces for each application and store data with the same application identifier written by different write commands within the same subspace, ensuring that data corresponding to the same application identifier is physically stored contiguously on the SSD. Even when write commands with different application identifiers are mixed together on the same SSD, data corresponding to the same application identifier can still be stored contiguously at physical addresses.

[0031] Optionally, in one embodiment, physical address contiguousness refers to contiguous physical addresses managed by the Flash Translation Layer (FTL) of the solid-state drive (SSD). A mapping table between application identifiers and flash physical block groups of the SSD can be established in the SSD's FTL, with each flash physical block group constituting a storage subspace. Each physical block group contains pre-allocated contiguous physical blocks. The SSD controller receives a write command from the host, which includes an application identifier and data to be written. The controller's FTL module determines the corresponding physical block group and the current write pointer within that physical block group based on the mapping table and the application identifier. The controller writes the data to be written to the physical page pointed to by the current write pointer and updates the write pointer to point to the next contiguous physical page. By maintaining a dedicated write pointer for each application identifier and writing sequentially within the pre-allocated contiguous physical blocks, data corresponding to the same application identifier is stored contiguously at physical addresses on the SSD. The entire storage subspace can then be read at once based on the application identifier. This allows multiple data items written separately by different write commands with the same application identifier to be read simultaneously, and since these data items are contiguous in physical address, sequential reading can significantly accelerate the read speed.

[0032] Optionally, in one embodiment, the mapping relationship can be implemented using a static lookup table. This is a straightforward implementation. The firmware maintains a table where each row constitutes a mapping entry. The table uses the application identifier as the key and a structure describing the storage subspace as the value. This structure contains at least the following information: physical start address (the starting physical block address of the subspace in the NAND flash memory); total space size (the total amount of physical space reserved for the application identifier); and a current write pointer (pointing to the next writable physical location within the subspace). When a write command with a specific application identifier is received, the SSD controller quickly locates the corresponding storage subspace and its current write position by querying this table, and continuously writes data to this position.

[0033] Optionally, in another embodiment, the mapping relationship can be implemented using a dynamic segment linked list. To utilize flash memory space more flexibly, an application's storage subspace can consist of one or more physically contiguous "segments." In this approach, the mapping relationship links the application identifier to one or a set of segment descriptors. Each segment descriptor records the start address and length of a contiguous physical block. When a segment is full, the firmware searches for the next available contiguous free block as the new segment and adds its information to the segment list of that application identifier. This approach allows for the aggregation of multiple non-contiguous large blocks of space for the same application, while maintaining the physical continuity of data within each block.

[0034] By establishing a mapping between application identifiers and contiguous storage subspaces within a solid-state drive (SSD), and writing data from the same application to these specified storage subspaces physically contiguously based on the application identifier carried in the host write command, logical random I / O access on the host side can be converted into sequential read / write operations on the SSD physical storage. This conversion greatly leverages the physical characteristic of NAND flash memory that sequential access is much faster than random access, thus significantly improving I / O access speed for specific applications and drastically reducing read / write latency. Simultaneously, because data is physically centralized, the "garbage collection" operations required within the SSD due to data dispersion are reduced, lowering the write amplification factor. This not only further improves performance but also extends the lifespan of the SSD. As a low-level optimization compatible with the standard NVMe protocol, this design can bring a seamless performance leap to upper-layer applications (especially AI, big data, and other applications requiring high-performance I / O).

[0035] Optionally, in one embodiment, the reading process further includes the following steps: the solid-state drive receives a read command from the host, the read command including an application identifier; the solid-state drive determines the target storage subspace to be read based on the application identifier and mapping relationship in the read command; the solid-state drive reads all data in the determined target storage subspace based on the application identifier and returns it to the host.

[0036] This reading method can accelerate the reading of data for training AI image classification models. A typical AI application scenario involves training an image classification deep learning model (e.g., ResNet) using a massive dataset (e.g., ImageNet) containing millions of small image files.

[0037] In a standard AI training process, the data loader needs to read tens of thousands of batches of data from the hard drive in each training epoch. A batch typically contains dozens to hundreds of independent image files. Traditionally, this means initiating tens of thousands of independent file open and read operations. These operations incur significant I / O overhead, including: file system overhead (each read requires the host operating system to traverse the file system's directory tree, search for metadata, and perform logical address to physical address translation); system call overhead (numerous read() system calls cause frequent switching between user mode and kernel mode, consuming CPU resources); and random access (if these small files are physically scattered, the read operation becomes a large amount of random I / O, which is much slower than the sequential read speed of a solid-state drive). These bottlenecks cause data loading speed to lag behind the GPU's computing speed, leaving expensive GPU resources idle for extended periods, severely impacting overall training efficiency.

[0038] The steps for an example of reading and writing a dataset in an AI training scenario are as follows:

[0039] Step 1: Writing the dataset and establishing the "AI training dataset subspace".

[0040] 1. Define Application Identifier: During the training data preparation phase, the user or data preparation tool defines a unique application identifier for the entire ImageNet dataset, such as the string "AI-TRAIN-IMGNET-V1".

[0041] 2. Data Writing: Users use a specialized tool to write all of the more than one million JPG image files in the dataset to the solid-state drive (SSD) of this invention. Each file write command is appended with the same application identifier "AI-TRAIN-IMGNET-V1".

[0042] 3. SSD Internal Operations: The SSD firmware recognizes that these write commands all carry the same application identifier. Internally, the SSD establishes a mapping: "AI-TRAIN-IMGNET-V1" -> Storage Subspace A. The SSD writes all received image data as a continuous data stream to a pre-allocated or dynamically expanded, physically contiguous "Storage Subspace A". After writing, Storage Subspace A physically becomes a huge, contiguous block of data containing the entire ImageNet dataset. The SSD records the starting physical address and length of this subspace.

[0043] Step 2: Efficient data reading during AI model training.

[0044] A single read command is initiated. After AI model training begins, the data loader of the AI ​​framework (such as PyTorch or TensorFlow) is configured not to read files one by one by filename. Instead, it initiates a single, specially crafted read command to the host driver. The key parameter in this read command is the previously defined application identifier: "AI-TRAIN-IMGNET-V1". The semantics of the command are: "Return all data in the storage subspace associated with this application identifier in one go".

[0045] The SSD receives the read command carrying the identifier "AI-TRAIN-IMGNET-V1". Based on its internal mapping, the SSD quickly locates the physical start address and length of storage subspace A. The SSD's controller drives its flash array to perform a large-scale, uninterrupted sequential read operation, transferring all data in the entire storage subspace A (i.e., the entire dataset) to the host's memory (RAM) at high speed and in a streaming manner.

[0046] The host memory now contains a huge contiguous block of memory holding all the image data. The AI ​​framework's data loader can quickly build each required data batch simply by indexing and slicing this data block in memory, and then feed it to the GPU for training. Parsing data from memory is much faster than reading files from disk.

[0047] Compared with traditional methods, this embodiment produces the following technical effects:

[0048] An exponential reduction in I / O overhead and latency. From millions to one: What used to be millions of read() system calls for millions of files is simplified to a single, highly optimized read command. This virtually eliminates the CPU overhead and latency associated with file system lookups, metadata processing, and context switching. This approach bypasses the slow file system layer in the host OS, enabling more direct communication between the application and the SSD physical storage, thus avoiding the performance bottlenecks of the traditional I / O stack.

[0049] Achieve optimal SSD sequential read performance. Since the dataset is physically contiguously stored on the SSD, the single read operation is performed at the highest sequential read speed achievable by the SSD hardware. This contrasts sharply with the numerous inefficient random reads caused by file fragmentation in traditional methods. The extremely high data read throughput ensures that the data supply speed can consistently match or even exceed the processing speed of the GPU, keeping the expensive computing units at full capacity at all times, thereby significantly reducing the overall AI training time.

[0050] The host-side data management logic has been simplified. The host-side AI framework no longer needs to manage a complex list containing millions of file paths, nor handle cumbersome exceptions such as file non-existence or read errors. Its data loading logic is simplified to requesting a data block and then processing it in memory. This reduces the development and maintenance complexity of upper-layer applications.

[0051] This improves the atomicity of data access. The entire dataset is treated as a single unit for operation. This provides a solid foundation for future implementation of more complex advanced features such as dataset version control, snapshots, and consistent backups.

[0052] In summary, this embodiment perfectly solves the small file I / O storm problem in AI training scenarios through the innovative model of "application identifier -> target subspace -> one-time full read", transforming data access from a bottleneck to a performance advantage, and providing strong technical support for accelerating the research and iteration of AI models.

[0053] Optionally, in one embodiment, the SSD space can be managed in a hierarchical grouping manner. Specifically, the application identifier includes a first part and a second part; the solid-state drive includes multiple primary storage subspaces, and at least one primary storage subspace includes multiple secondary storage subspaces. The solid-state drive determines the target primary storage subspace based on the mapping relationship and the first part of the application identifier in the write command; the solid-state drive further determines the target secondary storage subspace within the target primary storage subspace based on the second part of the application identifier in the write command. In one example, the first part can represent the application category, and the second part can represent the application subcategory. In one example, application identifiers ID1-ID4 each correspond to one primary storage subspace; application identifiers ID5-ID7 collectively correspond to one primary storage subspace; application identifier ID8 not only corresponds to one primary storage subspace, but also further includes two secondary storage subspaces within that primary storage subspace; application identifier ID9 not only corresponds to one primary storage subspace, but also further includes five secondary storage subspaces within that primary storage subspace; other application identifiers (i.e., application identifiers other than ID1-ID9) collectively correspond to one primary storage subspace.

[0054] Optionally, in one embodiment, the application identifier is a string, with the first few characters forming a first part and the last few characters forming a second part. In another embodiment, the application identifier is a binary bit string, with the first few bits forming a first part and the last few bits forming a second part.

[0055] Optionally, in one embodiment, the mapping relationship can adopt a hierarchical structure. For example, a 32-bit application identifier can be split into two parts: the high 16 bits are used as a first-level index, and the low 16 bits are used as a second-level index. The controller first uses the high 16 bits to find the pointer to the second-level mapping table in the first-level mapping table, and then uses the low 16 bits to find the final storage subspace descriptor in the corresponding second-level mapping table. This tree structure can efficiently manage large amounts of hierarchical application data classification.

[0056] Optionally, in one embodiment, step 101 may further include: pre-allocating a storage subspace of a preset size as an initial storage subspace for each application identifier. The preset size may be a predetermined value, a value configurable by the host, or a value determined according to the type of the application identifier. Step 104 further includes: determining whether the remaining capacity of the target storage subspace is greater than or equal to the size of the data to be written; in response to the remaining capacity of the target storage subspace being greater than or equal to the size of the data to be written, writing the data to be written into the target storage subspace; in response to the remaining capacity of the target storage subspace being less than the size of the data to be written, dynamically expanding the capacity of the target storage subspace until its remaining capacity is greater than or equal to the size of the data to be written, and then writing the data to be written into the expanded target storage subspace. Dynamic expansion can be achieved, for example, by allocating new blocks, migrating data, etc. In one example, dynamically expanding the capacity of the target storage subspace includes allocating additional blocks of contiguous physical addresses from the free storage area of ​​the solid-state drive until the remaining capacity of the target storage subspace is greater than or equal to the size of the data to be written.

[0057] Optionally, in one embodiment, the solid-state drive (SSD) data access acceleration method further includes: the SSD periodically detecting the physical address continuity of each storage subspace; for storage subspaces with non-contiguous physical addresses, the SSD reschedules and migrates the data therein to improve the continuity of the physical addresses of each storage unit within each storage subspace. In one example, the SSD detects the physical address continuity of each storage subspace every preset time interval (e.g., every 24 hours). If the fragmentation rate is higher than a preset threshold (e.g., 10%), the SSD reschedules and migrates the data in the non-contiguous storage subspaces to contiguous physical address blocks through a garbage collection mechanism. In another example, the physical address continuity detection and corresponding data scheduling of each storage subspace can be manually initiated by an engineer when the system is idle.

[0058] Optionally, in one embodiment, the solid-state drive (SSD) includes multiple primary storage subspaces, and at least one primary storage subspace includes multiple secondary storage subspaces. The SSD determines the target primary storage subspace based on a mapping relationship and a first portion of the application identifier in the write command. The SSD identifies the access mode type of the data to be written, including sequential access mode and random access mode. Based on the access mode type of the data to be written, the SSD further determines the target secondary storage subspace within the target primary storage subspace. The access mode type of the data to be written can be a second portion of the application identifier, a parameter in the write command (independent of the application identifier), or a pre-agreed flag. In one example, random writes (such as metadata) can be placed in an SLC cache or low-latency media, while sequential writes (such as video streams) can be placed in a high-density media such as QLC.

[0059] Data access mode types can be identified in several ways. For example, the host can analyze the writing order and size of the data to be written to identify the access mode type. For instance, if the data block size exceeds a preset threshold and is written consecutively, it is a sequential access mode; otherwise, it is a random access mode. Furthermore, the host can inform the SSD of the access mode type by setting specific flags in the write command. As another example, the SSD can identify the access mode type of the data to be written by analyzing the continuity of the logical block addresses (LBAs) of the write request.

[0060] Data in sequential access mode can include video stream data, log data, or large file data, while data in random access mode can include index data, metadata, or structured record data.

[0061] Optionally, in one embodiment, when the solid-state drive (SSD) reads data from the target storage subspace, it employs a corresponding prefetch strategy based on the data access mode type. For data in sequential access mode, large-block prefetching is used; for data in random access mode, small-block prefetching or no prefetching is used. Large-block prefetching and small-block prefetching are relative concepts. For example, a first prefetch size can be used for large-block prefetching, and a second prefetch size smaller than the first prefetch size can be used for small-block prefetching. In one example, large-block prefetching is a prefetch with a size at least one flash erase block, and small-block prefetching is a prefetch with a size equal to one flash page.

[0062] Optionally, in one embodiment, the method of writing the data to be written is further optimized before step 104 to write the data to the target storage subspace at a faster speed. The optimization of the writing method can be varied:

[0063] In one example, multiple write requests with the same application identifier are aggregated in a cache to form an aggregated data block. When preset conditions are met, the aggregated data block is written to the target storage subspace as a single write operation. For example, the solid-state drive controller aggregates multiple small write requests belonging to the same application identifier and destined for the same target storage subspace into one or more large, contiguous data blocks in its internal cache (DRAM or SLC cache). When the cache is full, a certain time threshold is reached, or a specific refresh command is received, this large data block is then written sequentially to the target subspace of the main flash media (such as TLC / QLC). By converting a large number of inefficient random small writes into efficient sequential large block writes, write performance is greatly improved and write amplification is reduced.

[0064] In another example, before performing a write operation, the SSD controller aligns or pads the data to be written based on the characteristics of the physical flash memory where the target storage subspace it manages resides (e.g., a page size of 16KB). This ensures that every write operation is page-aligned, avoiding cross-page writes or the generation of invalid data, thus eliminating the need for costly read-modify-write operations. This reduces unnecessary internal data movement, lowers write latency, and extends flash memory lifespan.

[0065] In another example, the data to be written is broken down into multiple data segments; and multiple parallel flash channels of the SSD are used to write these data segments in parallel to different physical locations within the target storage subspace. For instance, when the SSD receives a large write command, the controller can identify it as a large data block belonging to a specific "application identifier." The SSD controller can then break this large data block down into smaller segments and simultaneously write these segments to different physical flash chips allocated to that target storage subspace via its internal parallel channels. This can significantly increase write bandwidth and fully utilize the hardware parallelism of the SSD.

[0066] Optionally, in one embodiment, the solid-state drive (SSD) interacts with the host using the NVMe protocol, and the write command is an extended write command conforming to the NVMe protocol. For example, the write command is an extended write command conforming to the NVMe protocol, wherein an application identifier field is added to a custom section (e.g., a vendor-specific section) of the NVMe command structure.

[0067] The second embodiment of this application relates to a solid-state drive, comprising: a memory for storing computer-executable instructions; and a processor coupled to the memory for implementing the steps of the solid-state drive data access acceleration method of the first embodiment when executing the computer-executable instructions.

[0068] Accordingly, embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the various method embodiments of this application. Computer-readable storage media include permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device. As defined herein, computer-readable storage media do not include transient computer-readable media, such as modulated data signals and carrier waves.

[0069] Furthermore, embodiments of this application also provide a computer program product, including computer-executable instructions that, when executed by a processor, implement the steps in the above-described method embodiments.

[0070] It should be noted that in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. In this application, if it refers to performing an action according to an element, it means performing the action at least according to that element, including two cases: performing the action only according to that element, and performing the action according to that element and other elements. Expressions such as "multiple," "repeatedly," and "various" include two, two times, two kinds, and more than two, more than two times, and more than two kinds.

[0071] The numbering used in describing the steps of a method does not inherently limit the order of these steps. For example, a step with a higher number does not necessarily have to be executed after a step with a lower number; it can be executed first and then second, or even in parallel, as long as this execution order is reasonable to someone skilled in the art. Similarly, multiple steps with consecutively numbered sequences (e.g., step 101, step 102, step 103, etc.) do not restrict other steps from being executed between them; for example, there can be other steps between step 101 and step 102.

[0072] This specification includes combinations of various embodiments described herein. Individual references to embodiments are made (e.g., "one embodiment," "some embodiments," or "preferred embodiments"); however, these embodiments are not mutually exclusive unless indicated to be mutually exclusive or are readily apparent to those skilled in the art. It should be noted that the word "or" is used in a non-exclusive sense throughout this specification unless the context explicitly indicates or requires it.

[0073] All references to this specification are considered to be incorporated integrally into the disclosure of this application so that they can serve as the basis for modifications if necessary. Furthermore, it should be understood that the above are merely preferred embodiments of this specification and are not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the scope of protection of one or more embodiments of this specification.

[0074] In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A method for accelerating data access on a solid-state drive, characterized in that, include: Establish a mapping relationship between application identifiers and storage subspaces in the solid-state drive (SSD), wherein the application identifier is used to uniquely identify one or a group of applications on the host. The solid-state drive receives a write command from the host, which includes an application identifier and data to be written. The solid-state drive determines the target storage subspace to be written to based on the mapping relationship and the application identifier in the write command; The solid-state drive (SSD) writes the data to be written to the target storage subspace. The starting position of this write is physically contiguous with the ending position of the last written data in the target storage subspace. Physical address contiguousness refers to the contiguous physical addresses managed by the flash translation layer of the SSD. A mapping table between application identifiers and flash physical block groups of the SSD is pre-established in the flash translation layer of the SSD. Each flash physical block group constitutes a storage subspace, and each physical block group contains pre-allocated contiguous physical blocks.

2. The solid-state drive data access acceleration method according to claim 1, characterized in that, Also includes: The solid-state drive receives a read command from the host, which includes an application identifier; The solid-state drive determines the target storage subspace to be read based on the application identifier in the read command and the mapping relationship; The solid-state drive reads all the data in the determined target storage subspace based on the application identifier and returns it to the host.

3. The solid-state drive data access acceleration method as described in claim 1, characterized in that, The application identifier includes a first part and a second part; the solid-state drive includes multiple primary storage subspaces, and at least one primary storage subspace includes multiple secondary storage subspaces. The solid-state drive determines the target storage subspace to be written to based on the mapping relationship and the application identifier in the write command, further including: The solid-state drive determines the target primary storage subspace based on the mapping relationship and the first part of the application identifier in the write command; The solid-state drive further determines the target secondary storage subspace in the target primary storage subspace based on the second part of the application identifier in the write command.

4. The solid-state drive data access acceleration method as described in claim 1, characterized in that, The step of establishing a mapping relationship between application identifiers and storage subspaces in the solid-state drive further includes: pre-allocating a storage subspace of a preset size for each application identifier as an initial storage subspace; The solid-state drive writes the data to be written to the target storage subspace, further including: Determine whether the remaining capacity of the target storage subspace is greater than or equal to the size of the data to be written; In response to the remaining capacity of the target storage subspace being greater than or equal to the size of the data to be written, the data to be written is written to the target storage subspace; In response to the fact that the remaining capacity of the target storage subspace is less than the size of the data to be written, the capacity of the target storage subspace is dynamically expanded until its remaining capacity is greater than or equal to the size of the data to be written, and then the data to be written is written into the expanded target storage subspace.

5. The solid-state drive data access acceleration method as described in claim 4, characterized in that, Also includes: The solid-state drive periodically checks the physical address continuity of each storage subspace; For storage subspaces with non-contiguous physical addresses, the solid-state drive reschedules and migrates the data within them to improve the continuity of physical addresses of storage units within each storage subspace.

6. The solid-state drive data access acceleration method as described in claim 1, characterized in that, The solid-state drive includes multiple primary storage subspaces, and at least one primary storage subspace includes multiple secondary storage subspaces. The solid-state drive determines the target storage subspace to be written to based on the mapping relationship and the application identifier in the write command, further including: The solid-state drive determines the target primary storage subspace based on the mapping relationship and the first part of the application identifier in the write command; The solid-state drive identifies the access mode type of the data to be written, and the access mode type includes sequential access mode and random access mode. The solid-state drive further determines the target secondary storage subspace within the target primary storage subspace based on the access mode type of the data to be written.

7. The solid-state drive data access acceleration method as described in claim 6, characterized in that, in, The data in the sequential access mode includes video stream data, log data, or large file data, while the data in the random access mode includes index data, metadata, or structured record data.

8. The solid-state drive data access acceleration method as described in claim 6, characterized in that, When the solid-state drive reads data in the target storage subspace, it adopts a corresponding pre-read strategy according to the access mode type of the data. Specifically, it uses large block pre-read for data in sequential access mode and small block or no pre-read for data in random access mode.

9. The solid-state drive data access acceleration method according to any one of claims 1-8, characterized in that, Before the solid-state drive writes the data to be written to the target storage subspace, it further includes: optimizing the writing method of the data to be written so as to write it to the target storage subspace at a faster speed.

10. The solid-state drive data access acceleration method according to any one of claims 1-8, characterized in that, The solid-state drive interacts with the host using the NVMe protocol, and the write command is an extended write command that follows the NVMe protocol.

11. A solid-state drive, characterized in that, include: Memory is used to store executable instructions for a computer; as well as, A processor, coupled to the memory, is configured to implement the steps of the method as described in any one of claims 1-10 when executing the computer-executable instructions.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1-10.

Images