JP2015036981A - Serial-read-optimization variable size flash translation layer - Google Patents

Abstract

PROBLEM TO BE SOLVED: To improve performance and efficiency for use of a flash storage.SOLUTION: A serial-read-optimization variable size flash translation layer is configured to be able to map a logical block address to a physical address in a nonvolatile memory (NVM). A map entry corresponding to the logical block address of a read command designates an address, an offset, and a length of a specific page in the NVM, the offset and the length are converted to the number of read units to be accessed in the specific page, and only the read units in the number are read from the specific page so as to access data of the read command. The read units in the number include data associated with at least one other logical block address optionally and/or selectively. Furthermore, a group of map entries such as a map page is stored in the NVM in a compressed form.

Description

Cross-reference to related applications Claims for the benefit of priority of the present application are made in the application data sheet of the present application, Request, or (if necessary) Transmittal. To the extent permitted by the type of the present application, this application incorporates the following applications by reference for all purposes: All of the following applications had the same applicant and applicant when the present invention was made.
US provisional application (reference number SF-11-15 and serial number 61 / 521,739): filed August 9, 2011. The first inventor is Earl T. Cohen. The title of the invention is “I / O DEVICE AND COMPUTING HOSTINTEROPERATION”.
US provisional application (reference number SF-11-15A, serial number 61 / 531,551): filed September 6, 2011. The first inventor is Earl T. Cohen. The title of the invention is “I / O DEVICEAND COMPUTING HOST INTEROPERATION”.
US provisional application (reference number SF-11-15B, serial number 61 / 543,666): filed October 5, 2011. The first inventor is Earl T. Cohen. The title of the invention is “I / O DEVICE AND COMPUTING HOSTINTEROPERATION”.
US provisional application (reference number SF-10-02, serial number 61 / 316,373): filed March 22, 2010. The first inventor is Radoslav Danilak. The title of the invention is “Accessing Compressed Data of Varying-Sized Quanta in Non-Volatile Memory”.
US application (reference number SF-10-02US and serial number 13 / 053,175): filed March 21, 2011. The first inventor is Radoslav Danilak. The title of the invention is “Accessing Compressed Data of Varying-Sized Quanta in Non-Volatile Memory”.
US provisional application (reference number SF-10-10, serial number 61 / 418,846): filed January 12, 2010. The first inventor is Jeremy IssacNathaniel Werner. The name of the invention is “DYNAMIC HIGHER-LEVEL REDUNDANCY MODEMANAGEMENT WITH INDEPENDENT SILICON ELEMENTS”.
US provisional application (reference number SF-10-10, serial number 61 / 543,707): filed May 10, 2011. The first inventor is Earl T. Cohen. The name of the invention is “SELF-JOURNALING AND HIERARCHICALCONSISTENCY FOR NON-VOLATILE STORAGE”.
US provisional application (reference number SF-10-06, serial number 61 / 543,707): filed October 5, 2011. The first inventor is Earl T. Cohen. The name of the invention is “SELF-JOURNALING AND HIERARCHICALCONSISTENCY FOR NON-VOLATILE STORAGE”.
PCT application (reference number SF-10-06PCT and serial number PCTUS1258583): filed October 4, 2012. The first inventor is Earl T. Cohen. The name of the invention is “SELF-JOURNALING AND HIERARCHICALCONSISTENCY FOR NON-VOLATILE STORAGE”.
US provisional application (reference number SF-10-12, serial number 61 / 755,169): filed January 22, 2013. The first inventor is Earl T. Cohen. The title of the invention is “Storage Address Space to NVM Address, Span, and Length Mapping / Converting”.

  Area: Advances in computing host and I / O device technology are needed to improve performance, efficiency, and practicality.

  Related Techniques: Techniques and concepts referred to herein, including those for context, definition, or comparison, are already known, unless explicitly stated to be known or known, or It should not be construed as part of the prior art. All references, if any, cited herein, including patents, patent applications, and publications, are hereby incorporated by reference, whether or not they are specifically incorporated herein. For purposes of reference, the entire contents are hereby incorporated by reference.

International Publication No.2012 / 075200

  The present invention may be applied in many ways, for example, processes, articles of manufacture, devices, systems, material compositions or configurations, computer readable storage media (eg, media in optical and / or magnetic mass storage devices such as disks, etc. Implemented as a computer readable medium such as a flash storage (an integrated circuit having a non-volatile storage device such as a flash storage device), or a computer network through which program instructions are sent via an optical or electronic communication link Can do. The detailed description discloses one or more embodiments of the invention that can improve cost, profitability, performance, efficiency, and utility in the above fields. The detailed description includes an introduction to facilitate understanding of the remainder of the detailed description. This introduction includes one or more exemplary embodiments of systems, methods, articles of manufacture, and computer readable media in accordance with the concepts disclosed herein and / or in the drawings. As described in greater detail in the “Conclusion”, the present invention includes all possible modifications and variations that fall within the scope of the claims.

FIG. 6 illustrates selected details of one embodiment of mapping logical block addresses to fixed size regions within a flash page. FIG. 4 illustrates selected details of one embodiment of mapping logical block addresses to variable size regions that optionally span flash pages. FIG. FIG. 6 illustrates one embodiment of a flash page that includes an integer number of read units. FIG. FIG. 4 illustrates selected details of one embodiment of mapping logical block addresses to variable size regions across one or more read units. Fig. 4 illustrates selected details of one embodiment of a read unit including a header and data. Fig. 4 illustrates selected details of one embodiment of a flash page including header and data. Fig. 4 illustrates selected details of one embodiment of a flash page including header and data. Fig. 4 illustrates selected details of one embodiment of various types of headers. Fig. 4 illustrates selected details of one embodiment of a map entry. Fig. 4 illustrates selected details of one embodiment of various compressed map entries. The flowchart of the read-out with respect to a non-volatile memory is shown. Fig. 4 illustrates selected details of one embodiment of an SSD controller.

  A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate selected details of the invention. The invention will be described in connection with those embodiments. These embodiments are merely examples, and the present invention is not limited to any or all of the embodiments disclosed in this specification and drawings, and is also encompassed by those embodiments. It should be understood that the present invention includes many alternatives, modifications, and equivalents. To avoid the monotony of the description, various word labels (“first”, “last”, “present”, “various”, “further”, “other”, “specific” , “Selected”, “several”, and “noticeable”) can be applied to individual sets of embodiments. However, the labels used herein are not intended to express quality or any form of preference or prejudice, but merely to conveniently identify their individual sets. Is intended. The order of some operations or processes of the disclosed processes can be changed within the scope of the present invention. Whenever embodiments are described as having differences in characteristics of processes, methods, and / or program instructions, the plurality of embodiments may be in accordance with predetermined or dynamically determined criteria. Other embodiments are contemplated that make one static and / or dynamic selection of a plurality of corresponding operating modes. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. Those details are provided for the purpose of example, and the invention may be practiced according to the claims without some or all of these details. In order not to unnecessarily obscure the present invention, technical matters known in the technical field related to the present invention have not been described in detail.

This introduction is provided only for the purpose of providing a quicker understanding of the detailed description, and the present invention is not limited to the concepts (including explicit examples) presented in this introduction. . Any introduction paragraph is, of course, a summary of the entire subject matter and is not intended to be exhaustive or limited to what is described. For example, the following introduction provides summary information limited by space and configuration only for certain embodiments. Many other embodiments, including those that are ultimately within the scope of the claims, are described throughout the remainder of the specification.

At least some of the various abbreviations (eg, acronyms) defined herein indicate certain elements that are used herein.

  The flash translation layer (FTS, also known as the flash translation layer) is the logic in the logical block address space (used, for example, by the host to perform I / O processing for I / O devices (input / output devices)). A block address (LBA) is mapped to a physical location in a non-volatile memory (NVM), such as a NAND flash non-volatile memory (NAND Flash NVM). This mapping operates on aligned units (aligned units) consisting of one or more logical blocks, called mapping units, where each mapping unit has a corresponding physical unit in which the mapping unit's data is stored. Have a position (but the physical position may be empty if the mapping unit has not been written, i.e. no changes have been made to the mapping unit). For example, in the case of a 4 KB mapping unit, eight consecutive (and typically eight sector aligned) SATA 512 byte sectors are mapped as a single unit. In general, a translation table (translation table) such as a map stores each translation (translation) from a logical block address associated with a mapping unit to a physical address in NVM and / or to other control information. To do this, it has one entry per mapping unit.

  Non-volatile memory, such as NAND flash, provides a writable (programmable) unit called a flash page. Flash pages contain multiple user (non-ECC) data bytes, and some or significant amount of extra space for metadata and error correction coding (ECC), typically NVM minimal writes It is a possible unit. Typical flash page sizes are 8 KB or 16 KB or 32 KB (user data), while typical mapping unit sizes are 4 KB or 8 KB (the term “user” data is used for flash pages). However, some flash pages store “system” data such as map data and / or checkpoint data, etc. User data is generally intended to point to non-ECC portions of flash pages ) Flash pages are organized or organized into a plurality of blocks, and typically there are 128, 256, or 512 flash pages per block. A block is the smallest size unit that can be erased, and a flash page must be erased before it can be (re) written to the flash page.

  As shown in FIG. 1, a conventional FTL is such that the number of user data bytes (or some of the user data bytes) in a flash page (eg, flash page 100) is a power of 2 (and / or sector size). The flash page is divided into an integer number of mapping units (each shown as “data” in FIG. 1). For example, if the user data per flash page is 16 KB and the mapping unit is 4 KB, each flash page contains 4 mapping units, and the FTL contains the address of each mapping unit (eg, LBA [m: u 110) to each flash page and one of the four mapping units in each flash page. That is, each map entry includes fields such as flash_page_address [n-1: 0] and mapping_unit_within_flash_page [k-1: 0]. Here, flash_page_address refers to a unique flash page within NVM, and mapping_unit_within_flash_page refers to one of the 2 k power-mapping-unit-size (mapping unit size) portions of each flash page (k is Constant for the entire NVM). The subpage address 104 is a combination of flash_page_address and mapping_unit_within_flash_page. In sector-based addressing, the lower bits (eg, LBA [u-1: 0] 111) of the logical block address are stored in multiple sectors (eg, one or more) in subpage 113 in the mapping unit. Specify sub-portion such as sector.

  Conceptually, as shown in FIG. 2, the variable size flash translation layer (VFTL) assigns the mapping unit address (eg, LBA [m: u] 110) to one or more flash page variable size regions. Mapping (because, for example, the mapping unit's data is compressed before being stored in flash, and / or in another example, the mapping unit may be a variable size portion, such as for object storage, etc. As it is written by the host). However, providing a complete byte address 204 and byte data length 206 for each map entry results in a larger map entry than a conventional FTL.

  VFTL is used in some solid state disks (SSD). These systems are typically designed for higher end clients and / or enterprise applications where random access performance constraints are a factor in the overall system design (driving factor). In order to optimize VFTL for low-end and / or mobile environments, changes are required to optimize sequential performance (sequential or continuous access performance) as a factor (driving factor). The new way of organizing and organizing user data and VFTL metadata enables a lower cost, more efficient low-end mobile NVM system where sequential read performance is a major limitation.

  In some embodiments, the VFTL performs mapping unit address to physical address mapping by mapping to an Epage (ECC page) address, also referred to as a “read unit” address. An Epage (or read unit) is the minimum amount of data that can be read from the NVM and corrected by an ECC code (ECC code) used to protect the contents of the NVM. That is, each read unit includes a certain amount of data and a corresponding ECC check byte that protects the data. In some embodiments, a flash page (such as flash page 100), and in some embodiments, a group of flash pages treated as a unit for writing, as shown in FIG. Divided into readout units.

  In various embodiments, the number of read units per flash page can be varied. For example, some parts of NVM use stronger ECC than others (using more bytes in the flash page for ECC) and have fewer read units and / or one read Less data available per unit. Alternatively, in another example, the number of read units per flash page changes as more NVM is used. This is because program / erase cycles tend to degrade NVM, so that more NVM is used (used up) requires a stronger ECC.

  According to various embodiments, the ECC used may be a Reed-Solomon code, a BCH code, a turbo code, an LDPC code, a polar code, a non-binary code. code), RAID code (RAID code), erasure code, any other error correction code, and any combination of these codes (including synthesis, concatenation, and interleaving) . A typical codeword size is in the range of 512 bytes (+ ECC bytes) to 2176 bytes (+ ECC bytes). A typical number of ECC bytes is in the range of just a few bytes to a few hundred bytes.

  In some embodiments, as shown in FIG. 4, the VFTL mapping may include the variable size (eg, compressed) mapping unit address (eg, LBA [m: u] 110), the read unit address 404 and the span. Maps to the multiple read units represented in each of the map entries as (multiple read units) 406. The read unit referenced by one of the map entries is in one or more (logically and / or physically) consecutive flash pages. That is, the plurality of read units optionally and / or selectively cross a flash page boundary. The map entry alone is not sufficient to locate the relevant data (because the entry only points to the read unit, not the position of the data in the read unit) Additional information (such as a header) in the read unit that is used is used to accurately locate the relevant data.

  In some embodiments, data is subdivided (in stripes) across multiple dies of NVM and written to a flash page. Subdividing write data across multiple dies (stripes) reduces write bandwidth by simply writing a single flash page to a given die once per strip (strip). It is advantageous in that it can be enlarged. A block constituting a strip (stripe) crossing a plurality of dies is called an Rblock. This is because in other embodiments and / or usage situations, RAID-like redundancy is added per Rblock, eg, using one redundant die. In various embodiments, some blocks of the NVM have defects and are skipped during writing, and therefore, by subdivision (striping), the die (rather than writing to a bad block flash page) There may be a “hole” in which one of the two is skipped. In these embodiments, “continuous” flash pages are contiguous in a logical order determined by the order in which they are written to the flash page.

  In various embodiments, the mapping shown in FIG. 4 creates a need to locate variable sized data within the read unit. As shown in FIG. 5, each read unit (eg, read units 500 and 510) has a set of headers 501, which include variable size data in one or more read units. It is typically written by hardware when it is "arranged non-overlapping like tiles" (eg, packed tightly with no extra space). The header is typically interpreted by other hardware to retrieve variable size data when the NVM is read. The variable size data is identified by a respective offset and length in one of the headers having a matching logical block address, and the data may optionally and / or optionally (eg, “data, It spans multiple read units (as illustrated by the variable size data indicated by “start” and “data, follow”).

  In various embodiments, the header is also used as part of recycling or recycling (garbage collection). That is, by including a logical block address (or equivalently a mapping unit address) in the header, it is possible to find variable size data in the read unit, and a specific one of the read units When a read unit is read (examine (or look for) a logical block address in the map), the map still points to the physical address of the particular read unit, or the read unit Means are provided for determining whether the variable size data in the read unit is still valid or overwritten (by determining whether it has been updated to point to another physical address).

  In some embodiments, dedicated hardware for retrieving data from the read unit based on the logical block address is required to operate with high efficiency for random reads. The dedicated hardware parses the headers in one or more read units to find one of the headers with a given logical block address, and is then associated with each length and offset Retrieve variable-size data. However, hardware-based solutions are expensive (in terms of silicon area and power). For low-end and / or mobile environments where sequential or continuous performance is more important than randomness, to reduce silicon area, save power, and achieve high sequential throughput rates Changes to VFTL are necessary.

  In some embodiments, the Sequential Read Optimization Variable Size Flash Translation Layer (SRO-VFTL) ensures that there are no gaps in the headers in the data, Data is tiled (not overlapping) into flash pages (or in some embodiments, a group of flash pages treated as a unit for writing). In this case, all headers are grouped in one part of the flash page. In other embodiments, headers are not used dynamically to access data (and so dynamically in some VFTL), but only for reuse and recovery. . Instead, the map entry contains the complete information needed to find variable-sized (eg, compressed) data in the flash page. By dividing the header and data into different parts of the flash page, a read unit containing only the header, a read unit containing both the header and data (but only one such read unit exists on a flash page), and A read unit containing only data can be provided.

  SRO-VFTL is optimized at low cost for sequential read throughput, but can operate relatively well for other criteria such as random read IOP, random write IOP, and sequential write throughput. However, removing hardware support for functions such as VFTL-type data tiling with a header in each readout unit inevitably places a heavy burden on the control processor.

  FIG. 6 shows a first embodiment of the SRO-VFTL flash page, and FIG. 7 shows a second embodiment of the SRO-VFTL flash page. The difference between the embodiment of FIG. 6 and the embodiment of FIG. 7 is whether the data continuing from the previous flash page 640 is before or after the header. Various embodiments and various arrangements of data within the flash page are contemplated.

According to various embodiments, a flash page (FP) includes one or more of the following.
A master header 610, an Rblock header 620 (eg, a header added in the first page of each block in the Rblock), and a header that includes zero or more additional packed headers 630 (however, Rblock headers are optionally and / or optionally included).
Data that continues from the previous flash page (part of the variable size data of the mapping unit) 640. However, the data is optionally and / or optionally included.
Packed (eg, optionally and / or selectively compressed) data of one or more mapping units 650 to fill a flash page. The end of the data may optionally and / or optionally continue into subsequent flash pages.
• Optional padding at the end of the flash page (included in 650). For example, padding
i) After the last variable-size data part added to the flash page, unused bytes smaller than the size of the header were left (so a new header was added to start another variable-size data part You ca n’t)
ii) Optionally and / or optionally if the specified number of headers per flash page is exceeded (so that the number of mapping units stored in a flash page is the number of mapping unit data Limited by the specified number of headers, not by size)
Used for.

  In some embodiments, SRO-VFTL recovery and / or reuse (ie, garbage collection) reads and / or only the header portion of each flash page, rather than all read units as in non-SRO-VFTL. It is also advantageous in that error correction and / or inspection can be performed. In the case of reuse, when it is determined that the data of the flash page must be rewritten, the data must be read out and error corrected. In some embodiments, the entire flash page is read for reuse, but only the header portion is error corrected until it is determined that the data in the flash page needs to be reused.

  In various embodiments, the number of headers per flash page is within a certain limit to the number of read units per flash page that need to be read to ensure that all headers are read from NVM. Limited to stay. In the embodiment of FIG. 6, only a sufficient number of read units must be read to contain the maximum number of headers. In the embodiment of FIG. 7, an additional number of read units must be read to accommodate the maximum size data (eg, continuation data 640) that is subsequently completed from the previous flash page. However, the embodiment of FIG. 7 determines the number of read units (or multiple read units) to access the data completion portion (hereinafter referred to as the data completion portion) following the previous flash page from the associated map entry. Be able to decide. This is because the number of bytes in the data completion part can be determined based on the respective offset and length of the associated map entry and the number of bytes of user (non-ECC) data in the previous flash page. . In addition, only the headers preceding the data completion part are optional Rblock headers (existing only on known flash pages, such as the first page of each block), and master headers (always present on each flash page) is there. In the embodiment of FIG. 6, in order to read the data completion part without accessing NVM twice, it must be assumed that there is a maximum number of headers (or the entire flash page must be read). Must not).

  In some embodiments, SRO-VFTL uses a single level map with multiple map entries. In other embodiments, the SRO-VFTL is a multi-level map, such as a two-level map with a first-level map (FLM) that points to a second-level map (SLM) page. Where each second level map page includes a plurality of map entries. In still other embodiments, the multi-level map has 3 or more levels, such as 3 levels. In some embodiments and / or usage situations, the use of multi-level maps allows only relevant portions (eg, for use) of the map to be stored (eg, cached) in local memory (eg, on-chip memory). This can reduce the cost of maintaining the map. For example, if a typical usage pattern activates a 1 GB logical block address space at any point in time, only a portion of the map sufficient to access that active 1 GB portion of the logical block address space. Is stored locally for faster access compared to storing in NVM. By reference to the outside of the active part of the logical block address space, the required part of one or more levels of the multi-level map is fetched (retrieved) from NVM, optionally and / or selectively , Other locally stored parts of the map are replaced.

  Each map entry is associated with (corresponding to) the address of one of the plurality of mapping units. A logical block address is converted to a mapping unit address, such as by removing zero or more least significant bits (LSBs) of the logical block address and / or adding a constant to the logical block address for alignment, etc. The unit address is looked up in the map to determine the corresponding map entry.

FIG. 8 shows details of one embodiment of various types of headers. In the example of FIG. 8, each header is formatted to fit exactly 6 bytes. According to various embodiments, the various types of headers satisfy one or more of the following.
・ All are the same size.
• Optional and / or selectively different sizes.
Each header includes a respective field that specifies the size of the header.
・ The size is different between different flash pages.
-Any combination of the above.

According to various embodiments, the header in the flash page includes one or more of the following.
A data header (810) indicating information associated with the variable size data portion. In some embodiments, the data associated with the data header begins in the same flash page where the data header appears. In other embodiments and / or usage situations, if only one flash page has the remaining space for the data header, all associated data starts in a subsequent flash page.
Map headers such as second level map (SLM) headers (820). The second level map header includes a first level map index (FLMI) that indicates which second level map page is stored (eg, for reuse and / or recovery of the second level map).
Log / checkpoint header (820). The log / checkpoint header indicates data used in reuse, recovery, error handling, debugging (debugging), or other special situations or conditions.
An Epoch header (830) used as part of the recovery (processing) to associate the data with the corresponding map / checkpoint information. There is typically at least one epoch header per flash page.
Master header (870). A master header (870) is used once for the flash page to provide information regarding the number of headers in the flash page, and non-header data (data that is not a header) begins in the flash page. There are various techniques for determining the start of non-header data, as shown in the embodiment of FIGS.
• Rblock header (880). The Rblock header (880) is used in a given flash page, such as the first flash page in each block of the Rblock.
Other types of headers (840) such as padding headers and checkpoint headers that support longer lengths.
In some embodiments, some of the headers include a TYPE field that provides multiple subtypes of the header. In various embodiments, some of the headers include a LEN (length) field that includes the length of the data associated with the header.

FIG. 9 shows selected details of one embodiment of map entry 900. According to various embodiments, the map entry includes one or more of the following:
• Physical flash page address.
• Offset within the flash page for variable size data items.
• Length of variable size data item.
-Other control information.
In some embodiments, the length is encoded, for example by offsetting a value of zero to correspond to a predetermined minimum length. In another embodiment, data compressed to be shorter than the predetermined minimum length is padded until its size is at least the predetermined minimum length.

  In various embodiments, the SRO-VFTL map entry is larger than the VFTL map entry. This is because the SRO-VFTL map entry stores the total offset and byte length (length expressed in bytes) of the corresponding data. Therefore, when map entries are stored in NVM, it is advantageous to reduce the size of those map entries. In typical applications, data is often read and written, at least with a granularity of sequential mapping units and / or an average number of sequential mapping units greater than one, often sequential and sequential. The map entry compression format that utilizes the same) can be implemented relatively inexpensively and achieves a high map compression rate. Map entry compression is further aided by the sequentially written data entering the same flash page until the flash page boundary is crossed. FIG. 10 shows selected details of one embodiment of various compressed map entries, including uncompressed (1010) and the same flash page address (1020) as the previous map entry (1020). ), Has the same flash page address as the previous map entry, has a flash page address (1030) starting at the offset at which the previous data ended, and has the same flash page address as the previous map entry And includes a flash page address (1040) starting at the offset at which the previous data ended and having the same length as the previous map entry.

  In some embodiments with multiple levels of maps, a cache of lower level map pages (such as leaf levels) is maintained. Cached map pages are in uncompressed form and can be accessed at high speed by the processor. When map pages are moved into the cache (from NVM, DRAM, etc.), they are uncompressed (ie, uncompressed). When map pages are flushed (or cleared) from the cache (for example because they have changed), they are compressed for storage (such as in NVM). According to various embodiments that use DRAM to reduce latency by storing part or all of the map page in DRAM, the map page in the DRAM can be in compressed form and uncompressed. Access (ie uncompressed) forms, selectively compressed or selectively uncompressed forms, and compressed versions of map pages in DRAM (ie compressed versions of those map pages) Stored in one or more of the forms having an indirection table (also referred to as an indirection table).

  In some embodiments, the host write data of the host write command is optionally and / or selectively compressed when the data arrives, and a FIFO-like manner in local memory (such as on-chip memory) Stored in For example, in some embodiments, host write data is from an NVM that includes firmware data structures, flash statistics, a portion of a map such as a cache that holds one or more pages of the map, and reclaimed read data. Stored in a unified buffer (for example, UBUF in FIG. 12), together with a read data, a header of data written to NVM, firmware code, and other usage patterns (unified buffer is also referred to as a unified buffer) . In other embodiments, one or more dedicated memories (storage devices) are used for various local storage needs of the SSD.

  For each mapping unit of data coming from the host, the SSD's control processor (eg, the CPU of FIG. 12) is assigned a respective mapping unit address, a respective local memory address, and / or a variable size (eg, compressed). ) One or more of the respective lengths of the respective mapping units of the host data are notified. The control processor can determine the write order of the flash pages and the total number of non-ECC bytes available on each flash page. The control processor can now determine the amount of headers and data placed on a given flash page according to the total number of non-ECC bytes available on the given flash page of the flash page. Yes. For example, the control processor accumulates the header for the given flash page (and keeps track of the number of bytes in the header used so far) until the given flash page is full, Add the variable size data and header of the mapping unit one by one to the given flash page. When the given flash page is full, the last part of the data of the last mapping unit of the mapping unit added to the given flash page may not fit on the given flash page If not, the last part is used as the data completion part of the flash page following the flash page, so that it can be used for new headers and data in the subsequent flash page The total number of non-ECC bytes is reduced.

  At a particular point in time, one or more flash pages can be filled with host write data and one or more flash pages can be filled with reuse data. For example, there are at least two bands (a FIFO-like series of Rblocks) filled with “hot” data (fresh data from the host) and “cold” data (reuse data). Continuing with this example, in various embodiments, host write data can be sent to either the hot band or the cold band, and the reuse data can be sent to either the hot band or the cold band.

The control processor is adapted to convert each series of mapping unit addresses, local memory addresses and lengths to one or more of the following:
A series of headers that are written on the flash page as the flash page header.
The first (or first) start address and the first (or first) length of successive portions (sequential portions) of local memory that are written to the flash page as the user data portion of the flash page.
A user data portion of a flash page containing at least a portion of the data of at least one mapping unit
The second (or second) start address and the second (or second) start address of the successive portion (sequential portion) of local memory to be written to the subsequent flash page as the user data completion portion of the subsequent flash page 2) length.
A user data completion part that contains part of the data of one mapping unit or is empty.
The number of zero or more padding bytes written to the flash page (or the padding bytes, where the padding bytes are used, for example, when the user data completion portion is empty and the flash page is not full).
The control processor can easily convert each series of mapping unit addresses, local memory addresses and lengths into a series of headers by reformatting, and generate a small number of direct memory access (DMA) commands Thus, it is advantageous in that a part constituting a flash page (a series of headers, a completed part of a previous flash page, a user data part, and an arbitrary padding byte) can be transferred to the NVM.

  In various embodiments, host write data compression can be optionally and / or selectively performed. In the first example, the host write command information selectively enables compression. In the second example, compression is selectively enabled as a function of the logical block address of the host write command. In the third example, the compression is selectively disabled (disabled) when the size of the host write data is not reduced by the compression of the host write data. If compression is not enabled, host write data is stored uncompressed. According to various embodiments, a map entry is compressed or uncompressed with corresponding data depending on the respective bit in each entry in the map and / or the length value stored in each map entry. Indicate. For example, if the mapping unit is 4 KB, a length of 4 KB in the map entry indicates that the associated data in the map entry is not compressed, while a length less than 4 KB is associated with the associated Indicates that the data is compressed.

  In some embodiments, the data selects the Rblock to be reused, reads the Rblock flash pages in the order in which the flash pages were written, and simply processes the read unit that contains the flash page header. Check the logical block address (or equivalently the mapping unit address) of each header that is a data header in the map to see if the data is still valid, and the data is still valid In some cases, the data is reused by creating appropriate new headers and DMA commands to assemble the data so that it can be reused as part of a new flash page. The new flash page is then written to NVM.

  FIG. 11 is a flowchart 1100 for reading the nonvolatile memory. In contrast to non-SRO-VFTL, a header in the read unit (or in a flash page) is not necessary to retrieve read data. Both non-SRO-VFTL and SRO-VFTL are advantageous in that they allow access to variable-size data and only require access to the read unit that contains the desired read data. It is.

In some embodiments, in response to receiving a read command that includes a logical block address (LBA) from the host (step 1110), the control processor and / or various hardware units can receive one of the following: The above can be executed.
Convert the logical block address to a mapping unit address (step 1114).
Examine the mapping unit address in a map that includes multiple map entries to determine one associated map entry of those map entries (step 1118).
Retrieve each flash page address of the associated map entry (step 1122) to determine if the associated flash page is in the flash page cache or needs to be read from NVM (step 1130) .
Take each offset and length from the associated map entry and according to the respective offset and length,
The number (or number) of multiple read units accessed in the associated flash page;
The read unit offset and the total read unit length in the flash page of the accessed read unit (the total length of the read unit);
Determine a DMA command to retrieve (eg, decompress) (compress (compress)) the data associated with the mapping unit address from the decoded version of the accessed read unit. ).
In response to determining that the associated flash page is not in the flash page cache, the accessed read unit of the associated flash page is read from NVM (step 1134) and the accessed read unit is Error correction decoding (error correction decoding) is executed on the data (step 1138) to generate corrected data.
Retrieve the associated data in the corrected data according to the respective offset and length of the associated map entry and decompress the retrieved data (step 1142).
In response to the read command, provide the decompressed data to the host (step 1146).
In the case of random reads, typically the number of read units accessed in the associated flash page to read the associated data is less than all the read units in the associated flash page. In addition, because the associated data is of variable size, the read unit accessing in the associated flash page for the first (or first) read command that points to the first (or first) logical block address. The number (or number) is the number (or number) of read units accessed in the associated flash page for the second (or second) read command that points to the second (or second) logical block address. ), The second (or second) logical block address is different from the first (or first) logical block address. In some embodiments, only the (number of) read units that access within the associated flash page are read from the associated flash page. That is, only (at least some) of the read units that contain a portion of the associated data are read to access the associated data.

  FIG. 12 shows selected details of one embodiment of the SSD controller 1200. In some embodiments, the SSD controller 1200 is capable of implementing SRO-VFTL. As shown in FIG. 12, the host interface (HIF) receives commands such as read and write commands, receives write data, and receives read data via an I / O receiver such as SerDes. Send. The command is sent to the CPU via shared memory (OpRAM). The CPU interprets these commands and controls the other parts of the SSD controller via shared memory (OpRAM). For example, the CPU sends DMA commands through shared memory (OpRAM) and various data paths such as Host Receive DataPath (HDRx) and Flash Transmit Datapath (FDTx) Receives a response from the transceiver unit.

  Write data from the host interface (HIF) is sent to the unified buffer (UBUF) via the Host Receive DataPath (HDRx). In various embodiments, Host Receive DataPath (HDRx) comprises logic (logic circuitry) for optionally and / or selectively compressing and / or encrypting host write data. In this case, optionally and / or selectively compressed and / or encrypted host write data is transferred from the unified buffer (UBUF) to the Flash Transmit Datapath (FDTx) and generic flash interface (GAFI). Sent to NVM via. In various embodiments, the Flash Transmit Datapath (FDTx) comprises logic (logic circuitry) for performing encryption and / or scrambling and / or error correction coding. In response to a host read command, data is read from NVM via a generic flash interface (GAFI) and sent to a unified buffer (UBUF) via a Flash Receive Datapath (FDRx). In various embodiments, the Flash Receive Datapath (FDRx) has error correction decoding and / or decryption and / or descrambling (de-scrambling) functions. In other embodiments, a separate error correction decoder (LDPC-D for implementing LDPC codes) can operate on the “raw” data stored in the unified buffer (UBUF) by the FlashReceive Datapath (FDRx). It has become. In this case, the decoded read data in the unified buffer (UBUF) is sent to the host interface (HIF) via the Host Transmit Datapath (HDTx). In various embodiments, the Host Transmit Datapath (HDTx) comprises logic (logic circuitry) for optionally and / or selectively decrypting and / or decompressing the decrypted read data. In some embodiments, a RAID-like And Soft-decision Processing (RASP) unit may additionally protect host write data and / or system data stored in NVM. RAID-like redundancy is provided and / or soft decision processing for use with LDPC-D can be performed.

  According to various embodiments, any processing of the control processor may be any CPU of one or more CPUs and / or one or more hardware units (hardware devices) and / or any of them. It is executed by a combination of For example, for writing, the conversion of a series of respective mapping unit addresses, local memory addresses and lengths into a series of headers may be in the same and / or similar format as the series of headers. Supported by hardware providing a series of respective mapping unit addresses, local memory addresses and lengths.

According to various embodiments, an SSD controller coupled to a non-volatile memory can use one or more of the following.
・ Conventional FTL.
-Variable size FTL.
-Sequential read (sequential read) of optimized variable size FTL.
Any combination of the above in different physical parts of the non-volatile memory.
Any combination of the above in different logical parts of the logical address space of the SSD controller.
• Raw physical access to non-volatile memory.
Any combination of the above under the control of a host coupled to the SSD controller.

  According to various embodiments, host write data is optionally encrypted before being written to NVM and decrypted (decrypted) after being read from NVM. In other embodiments, encryption is performed after compression of host-written data and decryption is performed before decompression of data being read for return to the host.

  Although the illustrated embodiments use SSDs, the techniques described in this specification and / or drawings are generally applicable to other I / O devices and / or data storage devices such as HDDs. it can.

Exemplary Embodiments Following an introduction to the detailed description, a group of exemplary embodiments are shown, which are explicitly listed as at least some “ECs” (combinations of examples). Providing additional descriptions of various types of embodiments in accordance with the concepts described herein and / or in the drawings, but the examples are mutually exclusive and exhaustive. Neither intended nor limited to those examples. The invention is not limited to those exemplary embodiments, but includes all possible modifications and changes within the scope of the claims and their equivalents.

EC1)
A method,
In the I / O device, receiving a read request sent to the I / O device interface via the host, the read request from the non-volatile memory of the I / O device. A step that is a request for reading data corresponding to an address; and
In response to receiving the read request,
Reads a specific entry from the plurality of entries in the map and responds to writing of data corresponding to the physical address of the specific page of the plurality of pages of the nonvolatile memory and the logical block address of the read request Obtaining the offset in the specific page relative to the previously stored compressed data (compressed data) and the byte length of the compressed data, wherein the specific map entry is the read A step associated with the logical block address of the request;
The offset in the specific page and the byte length of the compressed data with respect to the compressed data, the address of the first (or first) read unit among the plurality of read units in the specific page, and the specific Converting to the number (or number) of read units read from a page of
Reading only the number (or number) of read units from the particular page;
Performing error correction decoding (processing) on each of the read units read from the specific page to obtain corrected data;
Retrieving the compressed data from the corrected data according to an offset within the particular page with respect to the compressed data and a byte length of the compressed data;
Decompressing the compressed data to generate return data (data to be returned to the host);
Returning the return data to the host.

EC2)
A method,
In the I / O device, receiving a read request sent to the I / O device interface via the host, the read request from the non-volatile memory of the I / O device. A step that is a request for reading data corresponding to an address; and
In response to receiving the read request,
Reads a specific entry from the plurality of entries in the map and responds to writing of data corresponding to the physical address of the specific page of the plurality of pages of the nonvolatile memory and the logical block address of the read request Obtaining the offset in the specific page relative to the previously stored compressed data (compressed data) and the byte length of the compressed data, wherein the specific map entry is the read A step associated with the logical block address of the request;
The offset in the specific page and the byte length of the compressed data with respect to the compressed data, the address of the first (or first) read unit among the plurality of read units in the specific page, and the specific Converting to the number (or number) of read units read from a page of
Reading more than the number of read units from the specific page and less than all the read units in the specific page;
Performing error correction decoding on each of the read units read from the specific page to obtain corrected data;
Retrieving the compressed data from the corrected data according to an offset within the particular page with respect to the compressed data and a byte length of the compressed data;
Decompressing the compressed data to generate return data (data to be returned to the host);
Returning the return data to the host.

  EC3) The method of EC1 or E2, wherein the number of read units to be read is less than the number of all read units in the particular page.

  EC4) According to a combination of the offset in the specific page with respect to the compressed data and the byte length of the compressed data, and the amount of user data in the specific page, at least a part of the compressed data is non-volatile The method of EC1 or EC2, further comprising the step of determining whether one or more read units of a page following the page of memory are present.

  EC5) In response to the global redundant data update at the second processing node, each local redundancy calculation unit of the second processing node is configured to receive at least one of the disks of the second processing node. The method of EC4, wherein the second redundant data can be calculated according to the global redundant data update data for storage in some.

  EC6) The first (or first) page of the pages of the non-volatile memory includes a first number of read units, and the second (or second) of the pages of the non-volatile memory. The method of EC1 or EC2 above, wherein the page comprises a second number of read units, wherein the first number is different from the second number.

  EC7) The first (or first) page of the pages of the non-volatile memory includes a first amount of user data and the second (or second) of the pages of the non-volatile memory. The method of EC1 or EC2 above, wherein the page includes a second amount of user data, wherein the first amount of user data is different from the second amount of user data.

EC8)
In the I / O device, receiving a write request sent to the I / O device interface via the host, the write request being a request for writing data corresponding to the logical block address. Steps,
In response to receiving the write request,
Compressing the data corresponding to the logical block address to generate compressed write data smaller than the data corresponding to the logical block address;
Writing at least a first (or first) portion of the compressed write data to the particular page;
Storing the physical address of the specific page, the offset within the specific page with respect to the compressed write data, and the byte length of the compressed write data in the specific entry; The method of EC1 or EC2 above.

EC9)
The EC8 method, further comprising: writing a header to the particular page in response to receiving a request for the write data, wherein the header includes at least a portion of the logical block address of the request. And a byte length of the compressed data.

EC10)
The logical block address is a first (or first) logical block address of a plurality of logical block addresses, and at least one of the number of read units corresponds to at least one of the logical block addresses. The EC1 or EC2 method above, comprising some data.

  EC11) The method of EC1 or EC2, wherein at least one of the number of read units includes one or more headers in addition to a portion of the compressed data.

EC12)
A method,
In the I / O device, receiving a read request sent to the I / O device interface via the host, the read request from the non-volatile memory of the I / O device. A step that is a request for reading data corresponding to an address; and
In response to receiving the read request,
Reads a specific entry from the plurality of entries in the map and responds to writing of data corresponding to the physical address of the specific page of the plurality of pages of the nonvolatile memory and the logical block address of the read request And obtaining an offset in the specific page with respect to previously stored variable size data (hereinafter, variable size data is also referred to as variable size data) and a byte length of the variable size data. The particular map entry is associated with the logical block address of the read request; and
An offset in the specific page with respect to the variable size data and a byte length of the variable size data, an address of a first (or first) read unit among a plurality of read units in the specific page, and Converting to the number (or number) of read units read from the particular page;
Reading only the number (or number) of read units from the particular page;
Performing error correction decoding on each of the read units read from the specific page to obtain corrected data;
Retrieving the variable size data from the corrected data according to an offset within the specific page with respect to the variable size data and a byte length of the variable size data;
Executing the step of returning the retrieved data to the host.

EC13)
In the I / O device, receiving a write request sent to the I / O device interface via the host, wherein the write request includes variable size data corresponding to the logical block address, and the variable size data A step that is a request to write the size of
In response to receiving the write request,
Writing at least a first (or first) portion of the variable-size data on the particular page;
Storing the physical address of the specific page, the offset in the specific page with respect to the variable size data, and the byte length of the variable size data corresponding to the size of the variable size data in the specific entry; The method of EC1 or EC12, further comprising the step of:

Exemplary Implementation Techniques In some embodiments, a multi-node storage device or part (or more) of the device, eg, all or part of the I / O device HDD or SSD controller Various combinations of processing are specified by specifications compatible with processing by a computer system, in which case their HDD or SSD controller is a processor (such as a CPU), an I / O controller (such as a ROC chip), and , Interoperable (or interacting) with a processor or microprocessor or system-on-chip or application specific integrated circuit or hardware accelerator or other circuit that provides all or part of the above processing The specification includes hardware description language, circuit description, netlist description. Follow various descriptions such as descriptions, mask descriptions, layout descriptions, etc. Exemplary descriptions include variants of SPICE such as Verilog, VHDL, SPICE, PSpice, IBIS, LEF, DEF, GDS-II, OASIS, or In various embodiments, the process may be interpreted to generate, verify, or specify logic (logic circuits) and / or circuits suitable for inclusion in one or more integrated circuits. Any combination of compilation, simulation, and synthesis, according to various embodiments, each of the integrated circuits can be designed and / or manufactured according to various techniques. Is a programmable technology (such as a field or mask programmable gate array integrated circuit) or a cell (such as a fully or partially cell-based integrated circuit). Custom techniques include (substantially specialized, such as integrated circuits) full custom technology, any combination thereof, or any other technique with a design and / or manufacture compatible with the integrated circuit.

  In some embodiments, various combinations of all or part of the processing described by a computer-readable medium on which a set of instructions is stored may be performed by execution and / or interpretation of one or more program instructions, or By interpretation and / or compilation of one or more source and / or script language statements, or by execution of binary instructions generated by compilation, translation and / or interpretation information expressed in programming and / or script language statements To be implemented. These statements are compatible with any standard programming or scripting language (such as C, C ++, Fortran, Pascal, Ada, Java, VB Script, and Shell). One or more of the program instructions, language statements, or binary instructions are optionally stored in one or more computer readable storage media elements. In various embodiments, some or all of these program instructions, or various parts, may be implemented as one or more functions, routines, subroutines, internal (inline) routines, procedures (procedures), macros, or parts thereof. Is done.

Conclusion In the above description, several choices have been made, merely for the convenience of preparing text and drawings, unless such choices are shown or suggested to be otherwise, It should not be construed as conveying additional information regarding the structure or operation of the described embodiments. Examples of those choices include the specific organization or assignment of the display used to number the drawings, and the identification information of the elements (eg, calls) used to identify and refer to the features and elements of the embodiment. Includes specific organization or assignment of out (such as a balloon) or numerical display.

  The terms “comprising” or “comprising” are expressly intended to be interpreted as an abstract concept describing a logical set of non-limiting scope, and are “in” or “in” It is not intended to represent physical limitation unless explicitly followed by the term "."

  While the above embodiments have been described in some detail for purposes of clarity and understanding, the invention is not limited to those details provided. There are many embodiments of the present invention. The disclosed embodiments are illustrative and not restrictive.

  It will be appreciated that many variations are possible in construction, arrangement and use consistent with the above description and are within the scope of the claims. For example, in each component block, the interconnect, functional unit, bit width, clock speed, and type of technology used can be varied according to various embodiments. The names given to the interconnects and logic (logic circuits) are merely exemplary and should not be construed as limiting the disclosed concepts. The order and arrangement of the processes, operations, functional elements of the flowcharts and flowcharts can be changed according to various embodiments. Also, unless specified otherwise, ranges of values specified, maximum and minimum values used, or (type of I / O device technology and in registers and buffers Other specific specifications (such as the number of entries or stages) are merely exemplary for the described embodiments and are intended to change as packaging technology advances and changes. And should not be construed as limited thereto.

  Functionally equivalent techniques known in the art may be combined with various components, subsystems, processes, functions, routines, subroutines, internal (inline) routines, procedures (procedures), macros, or portions thereof. It can be used instead of the one described for implementation. In addition, many functional aspects of the embodiment include design constraints, faster processing (which makes it easier to migrate functions previously implemented in hardware) and software (formerly in software). Functions of embodiments that rely on high integration density technology trends that facilitate migrating the functions that have been implemented to hardware include hardware (eg, generally dedicated circuitry) or (eg, some type of It will be appreciated that it can be selectively implemented in software (using a programmed controller or processor). Specific changes in various embodiments include different partitioning, different forms of elements and configurations, use of different operating systems and other system software, use of different interface standards, network protocols, or communication links, different Depending on the use of the coding type and the specific engineering and business constraints of the particular application, there are other changes that are envisaged when implementing the concepts disclosed herein and / or the drawings. Included (but not limited to).

  Several embodiments have been described with details and environmental conditions well beyond those necessary to implement many aspects of the described embodiments to a minimum. Those skilled in the art will appreciate that in some embodiments, disclosed components or features are omitted without changing the basic cooperation between the remaining elements. Accordingly, many of the details disclosed are not required to implement various aspects of the described embodiments. To the extent that the remaining elements are distinguishable from the prior art, omitted components and features do not limit the concepts disclosed herein and / or the drawings.

All such changes in design are only minor changes to the teaching provided by the described embodiments. It is also understood that the embodiments described herein and / or in the drawings are broadly applicable to other computing and networking applications and are not limited to the particular application or industry of the described embodiments. Accordingly, the present invention should be construed as including all possible modifications and variations that fall within the scope of the claims.

Claims (1)

A method,
In the I / O device, receiving a read request sent to the I / O device interface via the host, the read request from the non-volatile memory of the I / O device. A step that is a request for reading data corresponding to an address; and
In response to receiving the read request,
Reads a specific entry from the plurality of entries in the map and responds to writing of data corresponding to the physical address of the specific page of the plurality of pages of the nonvolatile memory and the logical block address of the read request Obtaining the offset in the specific page relative to the previously stored compressed data and the byte length of the compressed data, wherein the specific map entry is stored in the logical block address of the read request. Associated steps, and
The offset in the specific page with respect to the compressed data and the byte length of the compressed data are read from the address of the first read unit of the plurality of read units in the specific page and the read from the specific page. Converting to the number (or number) of units;
Reading only the number (or number) of read units from the particular page;
Performing error correction decoding on each of the read units read from the specific page to obtain corrected data;
Retrieving the compressed data from the corrected data according to an offset within the particular page with respect to the compressed data and a byte length of the compressed data;
Decompressing the compressed data to generate return data;
Returning the return data to the host.

Images