Method for providing different data protection levels for multiple namespaces and storage device

Abstract

The present application claims a method and a storage device for providing different data protection levels for multiple namespaces, the method comprising the steps of: obtaining a namespace to which a write command for writing data into the namespace is directed in response to the write command; querying a namespace table to obtain namespace configuration information of the namespace indicated by the write command; and obtaining a data protection level of the namespace from the namespace configuration information.

Description

Technical Field

[0001] This application relates to storage devices, and more specifically, to methods and storage devices for providing different levels of data protection for storage devices with multiple namespaces. Background Technology

[0002] Figure 1 A block diagram of a solid-state storage device (SSD) is shown. The SSD 102 is coupled to a host computer to provide storage capabilities. The host computer and the SSD 102 can be coupled in various ways, including but not limited to connections via SATA (Serial Advanced Technology Attachment), SCSI (Small Computer System Interface), SAS (Serial Attached SCSI), IDE (Integrated Drive Electronics), USB (Universal Serial Bus), PCIe (Peripheral Component Interconnect Express), NVMe (NVM Express), Ethernet, Fibre Channel, and wireless communication networks. The host computer can be an information processing device capable of communicating with the storage device via the above methods, such as a personal computer, tablet computer, server, laptop computer, network switch, router, cellular phone, or personal digital assistant. Storage device 102 includes interface 103, control unit 104, one or more NVM chips 105, and DRAM (Dynamic Random Access Memory) 110.

[0003] NAND flash memory, phase change memory, FeRAM (Ferroelectric RAM), MRAM (Magnetic Random Access Memory), and RRAM (Resistive Random Access Memory) are common types of NVM.

[0004] Interface 103 is compatible with exchanging data with the host via methods such as SATA, IDE, USB, PCIe, NVMe, SAS, Ethernet, and Fibre Channel.

[0005] The control unit 104 is used to control data transfer between the interface 103, the NVM chip 105, and the DRAM 110. It is also used for memory management, host logical address to flash physical address mapping, erase leveling, bad block management, etc. The control unit 104 can be implemented in various ways, including software, hardware, firmware, or a combination thereof. For example, the control unit 104 can be in the form of an FPGA (Field-programmable gate array), an ASIC (Application Specific Integrated Circuit), or a combination thereof. The control unit 104 may also include a processor or controller, in which software executes to manipulate the hardware of the control unit 104 to process I / O (Input / Output) commands. The control unit 104 can also be coupled to the DRAM 110 and can access the data in the DRAM 110. FTL tables and / or cached I / O command data can be stored in the DRAM.

[0006] The control unit 104 includes a flash interface controller (or media interface controller, flash channel controller), which is coupled to the NVM chip 105 and issues commands to the NVM chip 105 in accordance with the interface protocol of the NVM chip 105 to operate the NVM chip 105, and receives the command execution results output from the NVM chip 105. Known NVM chip interface protocols include "Toggle", "ONFI", etc.

[0007] A memory target is one or more logic units (LUNs) within a NAND flash memory package that share a chip enable (CE) signal. A NAND flash memory package may include one or more dies. Typically, a logic unit corresponds to a single die. A logic unit may include multiple planes. Multiple planes within a logic unit can be accessed in parallel, while multiple logic units within a NAND flash memory chip can execute commands and report status independently of each other.

[0008] Data is typically stored and retrieved in pages on storage media, while data is erased in blocks. A block (also called a physical block) contains multiple pages. Pages on a storage medium (called physical pages) have a fixed size, such as 17664 bytes. Physical pages can also have other sizes.

[0009] In solid-state storage devices, the FTL (Flash Translation Layer) is used to maintain the mapping information from logical addresses to physical addresses. Logical addresses constitute the storage space of the solid-state storage device as perceived by upper-layer software such as the operating system. Physical addresses are the addresses used to access the physical storage units of the solid-state storage device. In related technologies, intermediate address formats can also be used for address mapping. For example, a logical address can be mapped to an intermediate address, and then the intermediate address can be further mapped to a physical address.

[0010] The table structure that stores the mapping information from logical addresses to physical addresses is called the FTL table. The FTL table is important metadata in solid-state storage devices. Typically, the data items in the FTL table record the address mapping relationships in the solid-state storage device at the data page level.

[0011] The FTL table comprises multiple FTL table entries (or entries). In one case, each FTL table entry records the mapping between a logical page address and a physical page. In another case, each FTL table entry records the mapping between multiple consecutive logical page addresses and multiple consecutive physical pages. In yet another case, each FTL table entry records the mapping between logical block addresses and physical block addresses. Still another case, the FTL table records the mapping between logical block addresses and physical block addresses, and / or the mapping between logical page addresses and physical page addresses. Solid-state storage devices include multiple NVM chips. Each NVM chip includes one or more dies (DIEs) or logic units (LUNs). Dies or logic units can respond to read and write operations in parallel. Multiple read, write, or erase operations on the same die or logic unit are executed sequentially.

[0012] A large block comprises physical blocks from each of multiple logical units (LUNs), also known as logical unit groups. Each logical unit can provide a physical block for a large block. For example, in... Figure 2 The schematic diagram of the large blocks shown depicts large blocks constructed on every 16 logical units (LUNs). Each large block comprises 16 physical blocks, each originating from one of the 16 logical units (LUNs). Figure 2 In the example, block 0 comprises physical blocks 0 from each of the 16 logic units (LUNs), while block 1 comprises physical blocks 1 from each logic unit (LUN). Blocks can also be constructed in a variety of other ways. Chinese patent application No. 201710752321.0 discloses variable-length blocks, the entire contents of which are incorporated herein by reference.

[0013] As an alternative, page stripes are constructed within large blocks, where physical pages with the same physical address within each logical unit (LUN) constitute a "page stripe". Figure 2In this context, physical pages P0-0, P0-1, ..., and P0-x of block 0 constitute page stripe 0. Physical pages P0-0, P0-1, ..., P0-6 are used to store user data, while physical pages 0-x are used to store checksum data calculated based on all user data within the stripe. Similarly, Figure 2 In this context, physical pages P2-0, P2-1, ..., and P2-x of block 0 constitute page stripe 2. Optionally, the physical page used to store the verification data can be located at any position within the page stripe.

[0014] To write data to the page stripe, the storage device's control unit (104) (see also...) Figure 1 A checksum calculator is provided. Taking the calculation of checksum data using an XOR operation as an example, for a page strip comprising N+1 physical pages, an XOR operation is performed on the user data of the N physical pages (e.g., (P0-0)XOR(P0-1)XOR(P0-2)XOR…XOR(P0-(N-1))), and the calculation result is written to the physical page (e.g., P0-N) where the checksum data is stored for the page strip. Optionally, multiple checksum calculators (e.g., M) are provided in the control unit (104) to simultaneously write data to the M page strips. The checksum calculator uses a cache (e.g., an XOR cache) to record intermediate results of the checksum data.

[0015] Page stripe parity data is used to protect user data within the page stripe. The method of generating the parity data defines the data protection level. For example, RAID (Redundant Arrays of Independent Drives) technology includes data protection levels such as RAID 1-5, RAID 10, and RAID 11.

[0016] Figure 3 This diagram illustrates how a storage device generates checksum data for page stripes.

[0017] The data to be written to NVM is cached in DRAM. Figure 3 (This is shown as data D1, D2, and D3). As an example, the data protection level of the storage device is "3+1", which generates a checksum for every three copies of data and records the three copies of data and their checksum in the page stripe.

[0018] The CPU of the control unit provides, for example, data D1 from DRAM to the media interface controller. The media interface controller writes data D1 into the NVM. The media interface controller also generates intermediate parity data DX for data D1 and records it in the XOR cache. For example, if data D1 is the first piece of data in a page stripe, the XOR cache is initialized to 0, and the data stored in the XOR cache is XORed with data D1, and the XOR cache is updated with the calculation result.

[0019] Next, the CPU provides data D2 from DRAM to the media interface controller. The media interface controller writes data D2 into the NVM. The media interface controller also XORs data D2 with the data stored in the XOR cache to generate new intermediate parity data DX, and updates the XOR cache with the calculation result. Next, the CPU provides data D3 from DRAM to the media interface controller. The media interface controller writes data D3 into the NVM. The media interface controller also XORs data D3 with the data stored in the XOR cache to generate new parity data DX, and updates the XOR cache with the calculation result.

[0020] The CPU also instructs the media interface controller to write the data DX in the XOR cache to the NVM, and the data D1, D2, D3 in the NVM are located on the same page strip as DX.

[0021] Optionally, the CPU also instructs the media interface controller to move the data in the XOR cache to DRAM.

[0022] Storage devices typically have a defined data protection level, and are formatted according to that level. Changing the data protection level also requires reformatting the storage device. This is done under the control of the CPU. Figure 3 The media interface controller can generate verification data according to various data protection levels.

[0023] The NVMe protocol also defines namespaces (NS). A namespace of size n is a collection of logical pages with logical page addresses from 0 to n-1. A namespace can be uniquely identified by its namespace ID. Summary of the Invention

[0024] Namespaces (NSs) present multiple virtual storage devices to the host coupled to the storage device. Although these virtual storage devices may be provided by the same storage device, each NS is treated as an independent virtual storage device by the host. Therefore, the host wants to implement independent formatting for one or more NSs and wants each NS to provide differentiated functionality or performance; for example, it wants each NS to have different data protection levels and to be able to adjust the data protection levels of one or more NSs without affecting the use of other NSs belonging to the same storage device.

[0025] The coexistence of multiple data protection levels in storage devices necessitates multiple methods for generating checksum data. Using the CPU to control the media interface controller to generate checksum data for each piece of user data offers the greatest flexibility, but also introduces the greatest workload to the CPU. Hardware calculation of checksum data using the media interface controller offers better performance, but lacks flexibility; typically, hardware circuitry must be designed and provided for calculating checksum data for a given data protection level, and the hardware struggles to adapt to changes in data protection levels. Therefore, a reasonable balance between performance and flexibility is needed to provide multiple data protection levels.

[0026] According to a first aspect of this application, a method for generating write data is provided, comprising the following steps: obtaining the data protection level M of a page strip and the data processing capability N of a media interface controller; when M is greater than N+1, performing the following steps: providing N copies of user data to the media interface controller, causing the media interface controller to generate intermediate check data for the N copies of user data; writing the N copies of data into the page strip; providing N-1 copies of user data and the intermediate check data to the media interface controller, generating check data DY based on the N-1 copies of user data and the intermediate check data; determining whether the sum of the user data and the intermediate check data provided to the media interface controller has reached M-1 copies of data; if so, instructing the media interface controller to write the generated check data DY into the page strip.

[0027] According to the first method of the first aspect of this application, if the sum of user data and intermediate verification data provided to the media interface controller does not reach M-1 copies of data, the step of providing N-1 copies of user data and the intermediate verification data to the media interface controller, and subsequent steps, shall continue.

[0028] According to the first or second method of the first aspect of this application, if the user data provided to the media interface controller is less than N-1 copies, specified data is also obtained, such that the sum of the obtained specified data and the user data provided to the media interface controller satisfies N-1 copies.

[0029] According to the third method of the first aspect of this application, the specified data is either all-zero data or random data.

[0030] According to the first to fourth methods of the first aspect of this application, the intermediate check data DX is indicated to the media interface controller to have a placeholder mark, and in response, the data with the placeholder mark is not written to the page strip when the media interface controller writes data to the page strip.

[0031] According to the first to fifth methods of the first aspect of this application, intermediate check data DX is indicated to the media interface controller that the specified data has a placeholder mark, and in response, the media interface controller does not write the data with the placeholder mark into the page strip when writing data into the page strip.

[0032] According to the first to sixth methods of the first aspect of this application, where a placeholder mark is specified for data marking, data with the placeholder mark is not written when data is written to the page strip.

[0033] According to the first to seventh methods of the first aspect of this application, M and N satisfy the following relationship: M = N + m + 1, where M, N and m are positive integers and N > 1.

[0034] According to the first to eighth methods of the first aspect of this application, if M is less than N, the following steps are performed: providing M-1 copies of user data to the media interface controller; acquiring specified data such that the sum of the acquired specified data and the M-1 copies of user data satisfies N; generating check data DX for the M-1 copies of user data and the specified data; and writing the M-1 copies of user data and the check data DX into the page stripe.

[0035] According to the ninth method of the first aspect of this application, when providing M-1 copies of user data to the media interface controller, if the user data is less than M-1 copies, second specified data is also obtained, such that the sum of the obtained user data and the second specified data is M-1 copies.

[0036] According to a second aspect of this application, a storage device is provided, including a control component, which performs the method described above.

[0037] According to a third aspect of this application, a storage device is provided, comprising a CPU, a media interface controller, DRAM, and a page stripe, wherein: the DRAM caches user data to be written to NVM; the CPU provides N copies of the cached data in the DRAM to the media interface controller based on the data processing capability N of the media interface controller; when the media interface controller determines that M is greater than N, it performs the following steps: caching N copies of user data and generating intermediate check data DX for the N copies of user data, and writing the N copies of data into the page stripe; the media interface controller caches N-1 copies of user data and generates check data DY based on the N-1 copies of user data and the intermediate check data DX; and determines whether final check data has been generated for M-1 copies of data.

[0038] According to a fourth aspect of this application, a method for generating data with multiple protection levels is provided, comprising the following steps: in response to a write command to write data into a namespace, obtaining the namespace to be written by the write command; querying a namespace table to obtain namespace configuration information of the namespace indicated by the write command; obtaining the data protection level M and physical address space of the namespace indicated by the write command from the namespace configuration information; allocating a block constructed according to the data protection level from the physical address space; allocating a page stripe capable of carrying data from the block; if M is greater than N+1, performing the following steps, wherein N is the data processing capability of the media interface controller: providing N copies of user data to the media interface controller, causing the media interface controller to generate intermediate check data for the N copies of user data; writing the N copies of data into the page stripe; providing N-1 copies of user data and the intermediate check data to the media interface controller, generating check data DY based on the N-1 copies of user data and the intermediate check data; if the sum of the user data and the intermediate check data provided to the media interface controller reaches M-1 copies of data, instructing the media interface controller to write the generated check data DY into the page stripe.

[0039] According to the first method of the fourth aspect of this application, it further includes the step of: recording in a corresponding portion of the FTL table corresponding to the namespace indicated by the write command the address to be accessed by the write command and the physical address of the page stripe allocated for the namespace carrying the written data.

[0040] According to the second method of the fourth aspect of this application, if the sum of user data and intermediate verification data provided to the media interface controller does not reach M-1 data sets, the step of providing N-1 user data sets and the intermediate verification data to the media interface controller, and subsequent steps, shall continue.

[0041] According to the first to third methods of the fourth aspect of this application, if the user data provided to the media interface controller is less than N-1 copies, specified data is also obtained, such that the sum of the obtained specified data and the user data provided to the media interface controller satisfies N-1 copies.

[0042] According to the fifth method of the fourth aspect of this application, the specified data is either all-zero data or random data.

[0043] According to the first to sixth methods of the fourth aspect of this application, the intermediate check data DX is indicated to the media interface controller to have a placeholder mark, and in response, the data with the placeholder mark is not written to the page strip when the media interface controller writes data to the page strip.

[0044] According to the first to seventh methods of the fourth aspect of this application, intermediate check data DX is indicated to the media interface controller that the specified data has a placeholder mark, and in response, the media interface controller does not write the data with the placeholder mark into the page strip when writing data into the page strip.

[0045] According to the first to eighth methods of the fourth aspect of this application, where a placeholder mark is specified for data marking, data with the placeholder mark is not written when data is written to the page strip.

[0046] According to the first to ninth methods of the fourth aspect of this application, M and N satisfy the following relationship: M = N + m + 1; where M, N and m are positive integers and N > 1.

[0047] According to the first to tenth methods of the fourth aspect of this application, if M is less than N, the following steps are performed: providing M-1 copies of user data to the media interface controller; acquiring specified data such that the sum of the acquired specified data and the M-1 copies of user data satisfies N; generating check data DX for the M-1 copies of user data and the specified data; and writing the M-1 copies of user data and the check data DX into the page stripe.

[0048] According to the eleventh method of the fourth aspect of this application, when providing M-1 copies of user data to the media interface controller, if the user data is less than M-1 copies, second specified data is also obtained, such that the sum of the obtained user data and the second specified data is M-1 copies.

[0049] According to a fifth aspect of this application, a method for generating data with multiple protection levels is provided, comprising the following steps: in response to a write command to write data into a namespace, obtaining the namespace to which the write command is to be written; querying a namespace table to obtain namespace configuration information of the namespace indicated by the write command; and obtaining the data protection level of the namespace from the namespace configuration information.

[0050] According to the first method of the fifth aspect of this application, a physical address space is further obtained from namespace configuration information; a large block constructed according to a data protection level is allocated from the physical address space; and page stripes capable of carrying data are allocated from the large block.

[0051] According to a sixth aspect of this application, a method for writing data to a namespace is provided, comprising the following steps: in response to a write command to write data to a namespace, obtaining the namespace to which the write command is to be written; querying a namespace table to obtain namespace configuration information of the namespace indicated by the write command; obtaining the data protection level and physical address space of the namespace from the namespace configuration information; allocating a block constructed according to the data protection level from the physical address space; allocating a page stripe capable of carrying data from the block; and writing the user data indicated by the write command into the allocated page stripe.

[0052] According to a first method of a sixth aspect of this application, a media interface controller generates verification data for the user data based on the data protection level of the namespace indicated by the write command, and writes the verification data into the page stripe.

[0053] According to the first and second methods of the sixth aspect of this application, the method further includes the step of: recording in the corresponding part of the FTL table corresponding to the namespace indicated by the write command the address to be accessed by the write command and the physical address of the page stripe allocated for the namespace carrying the written data.

[0054] According to the second and third methods of the sixth aspect of this application, if the number of user data flowing through the media interface controller is less than the number of user data that generate verification data recorded in the namespace configuration information, then the stored verification data is an intermediate result.

[0055] According to the fourth method of the sixth aspect of this application, verification data is generated using intermediate results and newly written data into the namespace.

[0056] According to the first to fifth methods of the sixth aspect of this application, when the number of user data flowing through the media interface controller is equal to the number of user data generating verification data recorded in the namespace configuration information, verification data of the page strip corresponding to the namespace is generated, the verification data is written into the physical storage space corresponding to the namespace, and occupies the verification data page of the page strip.

[0057] According to a seventh aspect of this application, a storage device is provided that provides different data protection levels for multiple namespaces, characterized in that it includes: a control unit storing a namespace table, an FTL table, and one or more NVM chips; wherein the control unit performs the method described above.

[0058] According to a first device of the seventh aspect of this application, the namespace table includes at least one entry, each entry recording configuration information of one of the namespaces provided by the storage device.

[0059] According to a first device of the seventh aspect of this application, the configuration information includes the storage capacity of the namespace, the data protection level of the command space, the FTL table used, and one or more physical address ranges.

[0060] According to a first device of the seventh aspect of this application, the storage device further includes DRAM.

[0061] According to the first to fourth devices of the seventh aspect of this application, the FTL table comprises multiple parts, each part providing a translation from logical address to physical address for one of the namespaces provided by the storage device.

[0062] According to the first to fifth devices of the seventh aspect of this application, the entries in the namespace table record a portion of the FTL table used by the namespace corresponding to the entry.

[0063] According to the first to sixth devices of the seventh aspect of this application, the NVM chip provides the physical address space of the storage device.

[0064] According to the first to seventh types of devices of the seventh aspect of this application, the physical address space is divided into multiple parts, each part corresponding one-to-one with a namespace.

[0065] According to the first to eighth devices of the seventh aspect of this application, when a namespace is created, the size of the physical address space allocated to the namespace is determined based on the storage space size of the namespace and the data protection level.

[0066] According to the first to ninth devices of the seventh aspect of this application, a large block is constructed in the NVM chip according to the storage space size of the namespace and the data protection level.

[0067] According to the tenth device of the seventh aspect of this application, the data protection level indicates the error verification method used.

[0068] According to the eighth to ninth devices of the seventh aspect of this application, the configuration information of the namespace records one or more of the following: the number of blocks of the physical address space occupied, the construction method of the blocks, and the correspondence between the block number and the physical address.

[0069] According to the first to tenth devices of the seventh aspect of this application, the physical address space allocated for the namespace is greater than, equal to or less than the storage space required by the namespace.

[0070] According to the eleventh device of the seventh aspect of this application, when the physical address space allocated to a namespace is greater than the storage space required by the namespace, the additional storage space is used to provide large blocks available for garbage collection of the physical address space allocated to the namespace and / or to provide additional storage space for the namespace to write more data.

[0071] According to the eleventh to twelfth devices of the seventh aspect of this application, when the physical address space allocated to a namespace is less than the storage space required by the namespace, the size of the allocated storage space is dynamically adjusted according to the amount of data written to the physical address space allocated to the namespace, and the configuration information of the namespace is updated according to the adjustment result.

[0072] According to an eighth aspect of this application, a method for creating a namespace is provided, characterized by comprising the following steps: in response to a command to create a namespace, obtaining the size of the namespace to be created from the command space; and allocating physical storage space for the command space.

[0073] According to the first method of the eighth aspect of this application, physical storage space is allocated to the namespace based on the size of the namespace to be created and the data protection level.

[0074] According to the first method of the eighth aspect of this application, the data protection level is obtained from the command or a predetermined data protection level is used.

[0075] According to the first method of the eighth aspect of this application, physical address space is allocated for the command space from the unused physical address space of the storage device.

[0076] According to the fourth method of the eighth aspect of this application, the physical address space allocated for the namespace is equal to, less than or greater than the physical address space requested by the command space based on the size of the namespace to be created and the data protection level.

[0077] According to the fifth method of the eighth aspect of this application, the command indicates the additional storage space required for the namespace to be created.

[0078] According to the sixth method of the eighth aspect of this application, all namespaces share an unallocated physical address space.

[0079] According to the seventh method of the eighth aspect of this application, a large block allocated to the namespace is recorded in the namespace configuration information.

[0080] According to the eighth method of the eighth aspect of this application, one or more blocks are constructed in physical storage space, each block having a data protection level of its assigned namespace.

[0081] According to the ninth method of the eighth aspect of this application, a block table is created to record one or more blocks assigned to a specified namespace.

[0082] According to the ninth method of the eighth aspect of this application, the entries in the block table record the physical address of the block, the location of the physical block storing the check data, and one or more bad block markers.

[0083] According to the ninth method of the eighth aspect of this application, an entry is added to the namespace table to record the configuration information of the created namespace.

[0084] According to the ninth method of the eighth aspect of this application, the configuration information of the namespace includes the storage space size of the namespace, the data protection level, the allocated physical address space, the size or proportion of the additional storage space, and / or the large block table of the physical address space.

[0085] According to a ninth aspect of this application, a method for deleting a namespace is provided, comprising the steps of: in response to a command to delete a namespace, obtaining a namespace identifier from the command; obtaining an entry corresponding to the namespace identifier from a namespace table based on the namespace identifier; obtaining a physical address space and block allocated to the namespace from the entry; deleting the entry; and marking the block as unused.

[0086] According to the first method of the ninth aspect of this application, in response to the block being marked as unused, the data recorded in the block is erased. Attached Figure Description

[0087] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0088] Figure 1 This is a block diagram of a solid-state storage device in related technologies;

[0089] Figure 2 These are large schematic diagrams of related technologies;

[0090] Figure 3 A block diagram of a host and storage device according to one embodiment of this application is shown;

[0091] Figure 4 A block diagram of a host and storage device according to another embodiment of this application is shown.

[0092] Figure 5 A schematic diagram illustrating the process of writing data to an NS according to an embodiment of this application is shown;

[0093] Figure 6 A flowchart illustrating the processing of a write command according to an embodiment of this application is shown;

[0094] Figure 7 A flowchart illustrating the creation of an NS according to an embodiment of this application is shown;

[0095] Figure 8 This diagram illustrates how a storage device generates checksum data for page stripes.

[0096] Figure 9A , Figure 9B , Figure 9C A schematic diagram illustrating the generation of checksum data for page stripes by a storage device according to an embodiment of this application is shown;

[0097] Figure 10 A flowchart illustrating the writing of data to a page strip according to an embodiment of this application is shown;

[0098] Figure 11 A flowchart illustrating the writing of data to a page strip according to another embodiment of this application is shown. Detailed Implementation

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

[0100] Figure 4 A block diagram of a host and storage device according to an embodiment of this application is shown.

[0101] See Figure 4 The host is coupled with the storage. The host accesses the storage device by accessing multiple namespaces provided by the storage device (e.g., NS0, NS1, NS2, and NS3). The namespaces are provided according to, for example, the NVMe protocol.

[0102] According to embodiments of this application, the namespaces provided by the storage devices may have the same or different namespace configurations. Namespace configurations include, for example, the storage capacity of the namespace, the data protection level of the namespace, the FTL table used, and the physical address range.

[0103] The storage device includes a control unit, one or more NVM chips, and optionally DRAM. In some embodiments, the control unit integrates memory internally, eliminating the need for additional DRAM in the storage device. In still other embodiments, the control unit uses DRAM provided by the host. The DRAM is used to store checksum data generated for cached user data.

[0104] According to an embodiment of this application, the control component further includes a namespace table (abbreviated as NS table). The NS table includes multiple entries, and each entry of the NS table records configuration information for one of the namespaces provided by the storage device.

[0105] Optionally, the FTL table comprises multiple parts, each used to provide a translation from logical address to physical address for one of the NSs provided by the storage device. For example, an entry in the NS table records the portion of the FTL table used by that NS (e.g., the starting address of the FTL table in DRAM). Again, as an example, the portion of the FTL table used by that NS is calculated based on the NS number and the storage space size.

[0106] Optionally, one or more NVM chips in the storage device provide the physical address space of the storage device. The physical address space is divided into multiple parts (each part is abbreviated as NVM space, for example, NVM space 0, NVM space 1, NVM space 2, and NVM space 3; the physical address space also includes unallocated NVM space). The allocated NVM space corresponds one-to-one with NS.

[0107] When an NS is created, the size of the NVM space allocated to that NS is determined based on its storage space size and data protection level. For example, if the NS has 100GB of storage space and a data protection level of "5+1", then the allocated NVM space needs to store 100GB of user data and an additional 20GB of checksum data, thus requiring at least 120GB of NVM space. The NS configuration information also records the physical address range of the allocated 120GB of storage space.

[0108] The data protection level also corresponds to the block construction scheme in the NVM space. Blocks are constructed in the NVM space according to the data protection level. For example, if the data protection level of the created NS is "2+1", then the constructed block includes 3 physical blocks, where 2 physical blocks store user data and 1 physical block stores checksum data. As another example, if the data protection level of the created NS is "a+b", then the constructed block includes a+b physical blocks, where a physical blocks store user data and b physical blocks store checksum data, where a and b are both positive integers. Further, optionally, physical blocks belonging to the same block are provided by different logical units (LUNs) to ensure parallelism in data access within the block.

[0109] Optionally, the data protection level also indicates the error verification method used. For example, the verification data may be obtained by XORing the user data or by performing RS encoding on the user data.

[0110] The NS configuration information also records information such as the number of blocks in the NVM space, the construction method of the blocks, and the correspondence between the block number and the physical address.

[0111] Optionally, the allocated NVM space is larger than the storage space required to store the user data and checksum data of the NS. This additional storage space provides larger blocks available for garbage collection of the NVM space. Some NSs also have write data requirements. Since the NVM chip has a limited number of erase / write cycles, providing more additional storage space through the NVM space allocated to the NS also allows for accommodating larger write data volumes.

[0112] Optionally, the allocated NVM space may be less than the storage space required to store the user data and verification data of the NS. In the initial stages of NS use, when users write relatively little data to the NS or have not yet written any data, allocating less NVM space to the NS allows the storage device to provide more large blocks to other NSs, thereby improving the utilization of the storage device's physical storage resources. As users write more data to the NS, more large blocks are provided for the NVM space corresponding to that NS, increasing the allocated NVM space. The NS configuration information is also updated to record the large blocks allocated to its NVM space. Further, optionally, when a user deletes data in their NS, or when it is identified that there is insufficient valid data recorded in the NS, the large blocks allocated to the corresponding NVM space are also released, and the NS configuration information is updated to record the large blocks allocated to its NVM space.

[0113] The media interface controller generates checksum data based on the user data to be written to the NVM space and caches the generated checksum data in DRAM. For example, with a+b data protection level, b pages of checksum data are generated only after a pages of user data are received. Before all a pages of user data are received, the checksum data calculated for each page of user data is cached in DRAM. Figure 3 The diagram illustrates the parity data generated and cached by DRAM for NS0 to NS3. Understandably, in response to the final generation of page b parity data, the media interface controller writes the page b parity data into the large block storing page a user data, and also releases the DRAM storage space occupied by the page b parity data.

[0114] Figure 5 A schematic diagram illustrating the process of writing data to the NS according to an embodiment of this application is shown.

[0115] For example, the host writes data to NS0 ( Figure 5 In the middle, as instructed by (1). The command to write data (referred to as the write command) is sent to the control unit of the storage device ( Figure 5 In the middle, as indicated by (2). The write command indicates the address to be accessed and NS. The control unit queries the NS table based on the NS indicated by the write command ( Figure 5 In the process, as indicated by (3), the NS configuration information of the NS is obtained. From the NS configuration information, the data protection level (e.g., "2+1") and NVM space (e.g., NVM space 0) of the NS are obtained. A block constructed according to the data protection level "2+1" is allocated from NVM space 0, and a page strip capable of carrying data is allocated from the block. The media interface controller writes the user data indicated by the write command into the allocated page strip ( Figure 5In the middle, as indicated by (5). As the user data indicated by the write command flows through the media interface controller, the media interface controller also generates check data for it according to the data protection level of NS0 "2+1", and the generated check is stored in DRAM ( Figure 5 In the middle, as indicated by (4).

[0116] The FTL table corresponding to NS0 also records the address accessed by the write command and the physical address of the allocated page strip carrying the written data. This allows the host to retrieve the physical address from the FTL table corresponding to NS0 when accessing the written data via a read command, and then read the previously written data from that physical address. The read command indicates the NS. The NS table is accessed using the NS indicated by the read command to obtain the NS configuration information, which indicates the FTL corresponding to that NS. Optionally, the FTL table can be queried based on the NS number and address accessed by the read command, without needing to look up the NS table. For example, the NS number and address can be concatenated bit by bit as an index to access the FTL table.

[0117] If the user data flowing through the media interface controller is less than the required "2" pages for the page stripe, the checksum data recorded in DRAM is an intermediate result of the checksum data. When the user writes data to NS0 again, the media interface controller uses the intermediate result of the checksum data cached in DRAM and the newly written data to NS0 to continue generating checksum data. Figure 5 (Not shown in the image). In response to the user data flowing through the media interface controller filling the required "2" pages of the page stripe, the check data for that page stripe is also generated by the media interface controller, and then the check data in DRAM is also written to NVM space 0, occupying the required "1" page of check data for that page stripe.

[0118] As an example again, the host writes data to NS2. Figure 5 In the middle, as indicated by (6). The write command is sent to the control unit of the storage device ( Figure 5 In the middle, as indicated by (7). The write command indicates the address to be accessed and NS. The control unit queries the NS table based on the NS indicated by the write command ( Figure 4 In the process, as instructed by (8), the NS configuration information of NS 2 is obtained. From the NS configuration information, the data protection level (e.g., "15+1") and NVM space (e.g., NVM space 2) of the NS are obtained. A block constructed according to the data protection level "15+1" is allocated from NVM space 2, and a page strip capable of carrying data is allocated from this block. The media interface controller writes the user data indicated by the write command into the allocated page strip ( Figure 5In the middle, as indicated by (10). As the user data indicated by the write command flows through the media interface controller, the media interface controller also generates check data for it according to the data protection level of NS 2 "15+1", and the generated check is stored in DRAM ( Figure 5 (9) indicates.

[0119] If the user data flowing through the media interface controller to be written to NS2 is less than the required "15" pages for the page stripe, the checksum data recorded in DRAM is an intermediate result of the checksum data. When the user writes data to NS2 again, the media interface controller uses the intermediate result of the checksum data cached in DRAM and the newly written data to NS2 by the user to continue generating checksum data. Figure 5 (Not shown in the image). In response to the user data to be written to NS 2 filling the required "15" pages of the page stripe via the media interface controller, the check data for that page stripe is also generated by the media interface controller, and then the check data in DRAM is also written to NVM space 2, occupying the required "1" page of check data for that page stripe.

[0120] Figure 6 A flowchart illustrating the processing of write commands according to an embodiment of this application is shown.

[0121] According to an embodiment of this application, the host sends a write command to the storage device to write data into the storage device.

[0122] See Figure 6 When the control unit of the storage device receives a write command, it retrieves the NS configuration information of the namespace (NS) to be accessed from the NS table according to the namespace (NS) to be accessed by the write command. Based on the retrieved NS configuration information, it allocates a physical address and obtains the data protection level of the namespace (NS) to be accessed. Based on the obtained data protection level, it calculates the check data and then writes the data to the NVM.

[0123] Figure 7 A flowchart illustrating the creation of an NS according to an embodiment of this application is shown.

[0124] According to embodiments of this application, a storage device provides a command to create an NS. A host issues a create NS command to the storage device to create an NS within the storage device. The create NS command indicates the size of the NS to be created and, optionally, a data protection level. Alternatively, the create NS command may not specify a data protection level, and the storage device may create the NS using a default data protection level.

[0125] See Figure 7 When the control unit receives the Create NS command, it extracts the storage space size and optional data protection level of the NS to be created from the Create NS command.

[0126] In response, the control unit allocates NVM space for the NS to be created. The size of the NVM space to be allocated is determined based on the storage space size and data protection level indicated by the NS command. NVM space is allocated for the NS from the unused NVM space of the storage device. For example, if the storage space size of the NS to be created is 200GB and the data protection level is "15+1", then the allocated NVM space size is at least 200GB + 13.4GB + additional storage space. Optionally, if the allocated NVM space size is less than 200GB, additional large blocks are allocated to the NVM space when the data written by the user to the NS reaches or approaches 200GB.

[0127] Optionally, the NS command also indicates the additional storage space required for the NS to be created. For example, by default, an additional storage space equivalent to 10-20% of the NS's storage size is provided for the created NS, while the NS command can indicate a different amount of additional storage space. Alternatively, instead of allocating additional storage space to the NS, the unallocated NVM space of the storage device is shared among the NSs. For example, in response to NS 0 needing to receive garbage-generated data from an additional block, a block C is allocated from the unallocated NVM space, and the allocation of block C to NS 0 is recorded in NS 0's NS configuration table.

[0128] Optionally, the control unit also constructs one or more blocks in the NVM space, the constructed blocks satisfying the data protection level indicated by the NS command. Further optionally, a block table is created to record one or more blocks allocated to a specified NVM space, the entries in the block table recording the physical address of the block, the location of the physical block storing parity data, bad block markers, etc.

[0129] The control unit also adds entries to the NS table to record the configuration information of the created NS. The NS configuration information includes the NS's storage space size, data protection level, allocated NVM space, additional storage space size or proportion, and / or the large block table of the NVM space, etc.

[0130] According to another embodiment of this application, the storage device provides a command to delete an NS. The host issues a delete NS command to the storage device to delete the NS from the storage device. The delete NS command indicates the number or identifier of the NS to be created.

[0131] The control unit receives a delete NS command and extracts, for example, the number of the NS to be deleted from the delete NS command. It accesses the NS table using the NS number to retrieve and delete the entry corresponding to that NS number. Furthermore, based on the retrieved entries in the NS table, it obtains the NVM space allocated to that NS and its blocks, marking these blocks as unused so that they can be allocated to other NSs. Optionally, in response to marking these blocks as unused, it also erases the data recorded in these blocks.

[0132] Different data protection levels correspond to different methods of generating verification data. Under the control of the control unit, through... Figures 3-5 The media interface controller can generate verification data according to various data protection levels.

[0133] Figure 3 In the example, the CPU is required to move each piece of data from DRAM to the NVM, thus introducing a significant load on the CPU. The goal is to reduce the CPU load during the process of generating checksum data and writing it to the NVM chip.

[0134] Figure 8 This diagram illustrates how another storage device generates checksum data for page stripes.

[0135] Figure 8 In this example, the CPU provides all the user data required to write the page stripe to the media interface controller at once, thereby reducing the number of times the CPU is involved in writing data to the page stripe, in order to... Figure 3 The technical solution reduces the CPU load. For example, the CPU writes N data packets to the NVM chip at once via the media interface controller. The media interface controller processes the continuously received N data packets at once. Figure 8 In the example, N=3, and the data (D1, D2, and D3) are used to calculate checksum data. The generated checksum data is stored in the XOR buffer (denoted as data DX). The media interface controller also writes the N consecutively received data as user data into the page stripe of the NVM. The media interface controller also writes the XOR buffered data DX into the NVM as checksum data for the page stripe. Furthermore, data D1, D2, and D3, along with the checksum data DX, are stored in the same page stripe.

[0136] The following description uses a storage device with a data protection level of "3+1" as an example. Figure 8 In this embodiment, a verification data is generated for every three data sets, and the three data sets and their verification data are recorded in the page stripe of the NVM chip.

[0137] See Figure 8 The data to be written to NVM (data D1, D2, and D3) is cached in DRAM. Figure 8(Not shown in the image). The CPU of the control unit moves N copies (N=3) of data (D1, D2, and D3) from the DRAM to the control unit according to the specified data protection level. Figure 8 (1) indicates), and provides to the media interface controller ( Figure 8 (2) indicates). The media interface controller writes data D1, D2, and D3 into the page stripe in the NVM chip ( Figure 8 (3) indicates). The media interface controller also generates check data DX for data D1, D2 and D3 and records it in the XOR cache. Figure 8 (4) indicates). Understandably, Figure 8 The operation indicated by (3) and the operation indicated by (4) can be performed simultaneously. The media interface controller also writes the parity data DX generated in the XOR cache into the NVM chip. Figure 8 As indicated by (5), in the NVM chip, data D1, D2, D3 and check data DX are located in the same page strip.

[0138] As an example, the XOR cache is initialized to 0. The media interface controller operates on data D1, D2, and D3, which are XORed sequentially with the data stored in the XOR cache, and the XOR cache is updated with the calculation results. After the XOR operations on data D1, D2, and D3 with the data stored in the XOR cache are completed, the data DX in the XOR cache is the parity data DX corresponding to data D1, D2, and D3.

[0139] Optionally, the media interface controller initializes the XOR buffer with data D1, and then performs XOR operations on data D2 and D3 sequentially with the data stored in the XOR buffer, updating the XOR buffer with the calculation results. After data D2 and D3 have both completed the XOR operation with the data stored in the XOR buffer, the data DX in the XOR buffer is the parity data DX corresponding to data D1, D2, and D3.

[0140] according to Figure 8 In one embodiment, the media interface controller calculates checksum data for a given set of N data units, where N corresponds to the data protection level. Therefore, the command from the CPU to the media interface controller to write data to the NVM chip and generate checksum data also indicates the given data protection level, such as "N+1". Thus, in the process of generating a set of page stripes, the CPU intervenes only once, generating a single command for the media interface controller that indicates the physical addresses of the N data units and the page stripes. In another example, the CPU also separately instructs the media interface controller to write data from the XOR cache to the page stripes.

[0141] Optionally, the CPU also instructs the media interface controller to move the data in the XOR cache to DRAM.

[0142] Figure 8 In this embodiment, the media interface controller writes data to the page stripe only for a specified data protection level. When the storage device needs to provide multiple different data protection levels, it needs to... Figure 8 The embodiments are improved.

[0143] Figure 9A , Figure 9B and Figure 9C A schematic diagram illustrating the generation of checksum data for page stripes using a storage device according to an embodiment of this application is shown. Figure 9A In one embodiment, the CPU operates the media controller to write data to page stripes with multiple different data protection levels.

[0144] Figure 9A In this example, the media interface controller's processing capability lies in calculating checksum data for N data samples (N=3 for example), and the generated checksum data is stored in the XOR cache. The media interface controller also writes the N data samples as user data into the page stripes of the NVM. Furthermore, the media interface controller writes the XOR cached data DX into the NVM as checksum data for the page stripes.

[0145] The required data protection level is, for example, N+m+1 (for example, N=3, m=2), generating one checksum for every 5 data entries, with the 5 data entries and their checksum recorded on the same page strip.

[0146] See Figure 9A The data to be written to NVM (data D1, D2, and D3) is cached in DRAM. Figure 9A (Not shown in the image). The CPU of the control unit moves N copies (N=3) of data (D1, D2, and D3) from the DRAM to the control unit according to the specified data protection level. Figure 9A (1) indicates), and provides to the media interface controller ( Figure 9A (2) indicates). The media interface controller writes data D1, D2, and D3 into the page stripe in the NVM chip ( Figure 9A (3) indicates). The media interface controller also generates check data DX for data D1, D2 and D3 and records it in the XOR cache. Figure 9A (4) indicates). The media interface controller also moves the parity data DX generated in the XOR cache to the DRAM. Figure 9A (5) Instructions.

[0147] Continue reading Figure 9B Other data to be written to NVM (data D4 and D5) is also cached in DRAM. Figure 9B(Not shown in the image). Because the media interface controller accepts a data protection level of N (N=3), the CPU moves the checksum DX and data (D4 and D5) from DRAM to the control unit (…). Figure 9B (Indicated by (6) and (7)). The verification data DX is in Figure 9A In the processing demonstrated, data is generated by the control unit and then transferred to the DRAM. Figure 9B In the example, the CPU combines the check data DX in DRAM with the data D4 and D5 to be written to NVM to form N copies of data (N=3) acceptable for the media interface controller to generate check data. Therefore, from the perspective of the media interface controller, it still only needs to process the operation of generating check data for N copies of data.

[0148] according to Figure 9B In an embodiment, when the CPU instructs the media interface controller to write the parity number DX and data (D4 and D5) to the NVM, it also provides a "placeholder" mark for the parity data DX. Figure 9B (Indicated by the shaded line of data DX). Because the check data DX has a "placeholder" marker, the media interface controller uses the data with the "placeholder" marker to calculate the check data, but does not write the data with the "placeholder" marker to the NVM. See details. Figure 9B The media interface controller writes data D4 and D5 into the page stripe of the NVM chip. Figure 9B (8) indicates that (data DX was not written to the NVM chip because it had a placeholder mark). The media interface controller also generates check data DY for data D4, D5 and DX and records it in the XOR cache. Figure 9B (9) indicates). The media interface controller also moves the parity data DY generated in the XOR cache to the DRAM. Figure 9B (10) indicates). At this point, data D1-D5 and check data DY have been written into the NVM chip, and these data and check data together form a complete page strip.

[0149] Optionally, the media interface controller can also move the parity data DY generated in the XOR cache to DRAM.

[0150] As an example, before the CPU provides data D4, D5, and DX to the media interface controller to generate parity data DY, the XOR cache is initialized to 0. The media interface controller performs XOR operations on the data DX, D4, and D5 sequentially with the data stored in the XOR cache, and updates the XOR cache with the calculation results. After the data DX, D4, and D5 have all undergone XOR operations with the data stored in the XOR cache, the data DY in the XOR cache is the parity data DY corresponding to the data DX, D4, and D5.

[0151] Optionally, in response to the CPU providing data D4, D5, and DX to the media interface controller to generate parity data DY, the media interface controller initializes the XOR cache with the first data (e.g., data DX) of the received set of N (N=3) data, and sequentially XORs data D4 and D5 with the data stored in the XOR cache, updating the XOR cache with the calculation results. After data D4 and D5 have both undergone XOR operations with the data stored in the XOR cache, the data DY in the XOR cache is the parity data DY corresponding to data D4, D5, and DX. Further, since the XOR cache is initialized with data DX, while... Figure 9A After processing, the intermediate checksum data generated in the XOR cache is also DX, thus in Figure 9B Step (6) can provide only data D4 and D5 to the media interface controller without moving data DX from DRAM. However, this requires improvements to the media interface controller so that it can accept commands that indicate N-1 data and imply that the other data is data in the XOR cache, in addition to commands that indicate N different data (N=3).

[0152] By combination Figure 9A and Figure 9B The operation utilizes a media interface controller that only accepts data protection level "N+1" (N=3) to implement the writing of page stripes with data protection level "3+2+1".

[0153] And through combination Figure 9A and Figure 9C The operation involves writing page stripes with a data protection level of "3+1+1" using a media interface controller that only accepts data protection level "N+1" (N=3).

[0154] See Figure 9C The required data protection level is, for example, N+m+1 (for example, N=3, m=1), generating one checksum for every four data entries, with the four data entries and their checksum recorded in the same page strip. And according to... Figure 9A The processing involves generating (intermediate) check data DX from N data sets. The remaining m data sets, combined with the intermediate check data X, result in fewer than N data sets. Figure 9C The embodiments are designed to handle this situation.

[0155] Continue reading Figure 9C Other data to be written to NVM (data D4) is also cached in DRAM. Figure 9B (Not shown in the image). Since the media interface controller accepts data protection level N (N=3), the CPU moves the parity DX, data D4, and all-zero data (denoted as D0') from DRAM to the control unit ( Figure 9C(Indicated by (6) and (7)). The verification data DX is in Figure 9A In the processing demonstrated, data is generated by the control unit and then transferred to the DRAM. Figure 9C In the example, the CPU combines the check data DX in DRAM with the data D4 to be written to NVM and the data D0' consisting of all zeros to form N copies of data (N=3) acceptable to the media interface controller for generating check data. Thus, from the perspective of the media interface controller, it still only needs to process the operation of generating check data for N copies of data.

[0156] according to Figure 9C In an embodiment, when the CPU instructs the media interface controller to write the parity data DX and data (D4 and D0') to the NVM, it also provides a "placeholder" mark for the parity data DX and data D0'. Figure 9C (Indicated by the shaded lines of data DX and D0'). Because the check data DX and D0' have "placeholder" markers, the media interface controller uses the data with the "placeholder" markers to calculate the check data, but does not write the data with the "placeholder" markers to the NVM. See details. Figure 9C The media interface controller writes data D4 into the page stripe in the NVM chip. Figure 9C (8) indicates that (data DX and data D0' were not written to the NVM chip because they had placeholder marks). The media interface controller also generates check data DY for data D4, D0' and DX, and records it in the XOR cache. Figure 9C (9) indicates). The media interface controller also moves the parity data DY generated in the XOR cache to the DRAM. Figure 9C (10) indicates). At this point, data D1-D4 and check data DY have been written into the NVM chip, and these data and check data together form a complete page strip.

[0157] Optionally, the media interface controller can also move the parity data DY generated in the XOR cache to DRAM.

[0158] Therefore, when the combination of the user data to be written to the page strip and the previously generated intermediate check data still does not reach the N data required by the media interface controller to generate check data, the CPU obtains, for example, all-zero data D0' to make the data provided to the media interface controller reach the N data.

[0159] Figure 10 A flowchart illustrating the writing of data to a page strip according to an embodiment of this application is shown.

[0160] Figure 10The embodiment is applicable to the case where the media interface controller generates verification data for N copies of data and writes N copies of data to NVM, and the data protection level of the page stripe is "N+m+1", where m and N are both positive integers and N>1.

[0161] To write data to a page stripe, the CPU acquires N copies of data. These N copies of data are stored, for example, in DRAM.

[0162] The CPU provides the acquired N data sets to the media interface controller, instructing the controller to write these N data sets into the page stripes of the NVM. The media interface controller also generates first checksum data based on these N data sets. The CPU instructs the media interface controller whether each of the N data sets provided is a "placeholder" data set. The media interface controller writes non-"placeholder" data into the page stripes, while "placeholder" data is not written into the page stripes.

[0163] The CPU then retrieves N-1 copies of data to be written to the page stripe from, for example, DRAM. It combines these with the previously generated first checksum data to form N copies of data, which are then provided to the media interface controller. The CPU also indicates to the media interface controller that the N-1 copies of data retrieved from DRAM are non-"placeholder" data, while the first checksum data is "placeholder" data. In response, the media interface controller writes the N-1 copies of non-"placeholder" data to the page stripe, but not the "placeholder" data. The media interface controller also generates second checksum data based on the received N copies of data.

[0164] For example, m = N-1. At this point, all user data has been written to the page strip, and the second checksum is the checksum for that page strip. The CPU also instructs the media interface controller to write the second checksum to the page strip. The N copies of data written in the first write, the N-1 copies of data written in the second write, and the second checksum are all written to the same page strip.

[0165] Figure 11 A flowchart illustrating the writing of data to a page strip according to another embodiment of this application is shown.

[0166] Figure 11 The embodiment is applicable to the case where the media interface controller generates verification data for N copies of data and writes N copies of data to NVM, and the data protection level of the page stripe is "N+m+1", where m and N are both positive integers and N>1.

[0167] To write data to a page stripe, the CPU first obtains the data protection level of the data to be written. For example, the data protection level is M (M = N + m + 1).

[0168] The CPU acquires N data units (each unit being, for example, one page of a page stripe). These N data units are stored, for example, in DRAM. The CPU provides the acquired N data units to the media interface controller, instructing the controller to write these N data units to the page stripe of the NVM, and the media interface controller also generates intermediate checksum data based on these N data units. The CPU instructs the media interface controller whether each of the N data units provided is "placeholder" data. The media interface controller writes non-"placeholder" data to the page stripe, while "placeholder" data is not written to the page stripe. Optionally, the CPU also instructs the media interface controller to move data from the XOR cache to DRAM.

[0169] To generate checksum data for a page stripe with a data protection level of "N+m+1", checksum data needs to be calculated for N+m data units. The CPU identifies whether checksum data has already been generated for M-1 (=N+m) data units (1130). If checksum data has been generated for M-1 data units, the CPU instructs the media interface controller to write the generated checksum data (denoted as the final checksum data) into the same page stripe of NVM as the previously written M-1 data units. If checksum data has not yet been generated for M-1 data units, the CPU retrieves N-1 data units from DRAM. If the user-provided data to be written to NVM is less than N-1 units, one or more additional specified data units (e.g., all-zero data) or random data are retrieved, so that the user-provided data to be written to NVM and the additionally retrieved specified data combine to form N-1 data units. The CPU combines this N-1 data units with the intermediate checksum data previously generated by the media interface controller to form N data units and provides them to the media interface controller. The CPU also marks this intermediate checksum data as a "placeholder". If additional specified data is retrieved, the CPU also marks the additional specified data as a "placeholder".

[0170] The media interface controller uses the N-1 data sets acquired by the CPU and the intermediate check data to calculate new intermediate check data, which is then stored in the XOR cache. The media interface controller also writes data from the acquired N data sets that are not marked as "placeholders" to the NVM. Optionally, the CPU may also instruct the media interface controller to move data from the XOR cache to DRAM.

[0171] And in step 1130, the CPU identifies whether verification data (1130) has been generated for M-1 (=N+m) data sets, and continues with subsequent steps.

[0172] According to an embodiment of this application, a solid-state storage device is also provided, the device including a controller and a non-volatile memory chip, wherein the controller executes any of the methods provided in the embodiments of this application.

[0173] According to embodiments of this application, a program stored on a readable medium is also provided, which, when run by the controller of a solid-state storage device, causes the solid-state storage device to execute any of the methods provided according to embodiments of this application.

[0174] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and modifications.

Claims

1. A method for writing data into a namespace, characterized in that, Includes the following steps: In response to a write command that writes data to a namespace, the namespace to which the write command is to be written is obtained; Query the namespace table to obtain the namespace configuration information of the namespace indicated by the write command; Obtain the data protection level and physical address space of the namespace from the namespace configuration information; Allocate large blocks from the physical address space, constructed according to the data protection level; Allocate data-carrying page strips from the large block; Write the user data indicated by the write command into the allocated page strip; wherein, If M is greater than N+1, perform the following steps, where N is the data processing capability of the media interface controller; M is the data protection level of the namespace indicated by the write command: provide N copies of user data to the media interface controller, causing the media interface controller to generate intermediate check data for the N copies of user data; write the N copies of user data into the page stripe; provide N-1 copies of user data and intermediate check data to the media interface controller, and generate check data DY based on the N-1 copies of user data and intermediate check data; if the sum of the user data and intermediate check data provided to the media interface controller reaches M-1 copies of data, instruct the media interface controller to write the generated check data DY into the page stripe.

2. The method of claim 1, wherein the media interface controller generates verification data for the user data according to the data protection level of the namespace indicated by the write command, and writes the verification data into the page stripe.

3. The method as described in claim 1 or 2, wherein when the number of user data flowing through the media interface controller is equal to the number of user data generating verification data recorded in the namespace configuration information, verification data of the page stripe corresponding to the namespace is generated, the verification data is written into the physical storage space corresponding to the namespace, and occupies the verification data page of the page stripe.

4. A storage device that provides different data protection levels for multiple namespaces, characterized in that, include: It stores the namespace table control unit, the FTL table, and... One or more NVM chips; The control unit performs the method as described in any one of claims 1-3.

5. The storage device of claim 4, wherein the namespace table includes at least one entry, each entry recording configuration information of one of the namespaces provided by the storage device.

6. The storage device of claim 4, wherein the FTL table comprises a plurality of portions, each portion providing a translation from logical address to physical address for one of the namespaces provided by the storage device, wherein an entry in the namespace table records a portion of the FTL table used by the namespace corresponding to that entry.

7. The storage device of claim 4, wherein when the namespace is created, the size of the physical address space allocated to the namespace is determined based on the storage space size of the namespace and the data protection level.

8. The storage device of claim 4, wherein a large block is constructed in the NVM chip according to the storage space size of the namespace and the data protection level.

Images