KR102307382B1 - Variable-size flash translation layer - Google Patents

Abstract

A method using a variable size flash translation layer is disclosed. Step (A) receives a read request to read data corresponding to a logical block address from the non-volatile memory. Step (B) is a specific entry in the map to obtain (i) the physical address of a specific page of non-volatile memory, (ii) an offset within a specific page to previously stored compressed data, and (iii) the length of the compressed data. read the A specific entry is associated with a logical block address. Step (C) converts the offset and length into (i) the address of a given read unit in a particular page and (ii) the number of read units to be read. Step (D) reads the number of read units starting from at most a predetermined read unit from a particular page. Offset and length units are smaller than read units.

Description

Variable Size Flash Transformation Layer {VARIABLE-SIZE FLASH TRANSLATION LAYER}

This application is a U.S. Provisional Application No. 61/888,681, filed on October 9, 2013, U.S. Provisional Application No. 61/866,672, filed on August 16, 2013, and U.S. Provisional Application No., filed on January 22, 2013 61/755,169, each of which is hereby incorporated by reference in its entirety.

This application relates to U.S. Provisional Application No. 13/053,175, filed March 21, 2011, and to U.S. Provisional Application No. 61/316,373, filed March 22, 2010, each of which is hereby incorporated by reference in its entirety is integrated as

This application also relates to International Application No. PCT/US2 012/058583, having an international filing date of October 4, 2012, which claims the benefit of U.S. Provisional Application No. 61/543,707, filed October 5, 2011, and , each of which is hereby incorporated by reference in its entirety.

Field of the Invention

FIELD OF THE INVENTION The present invention relates generally to computing host and input/output device technology, and more particularly to methods and/or apparatus for implementing a variable size flash translation layer.

A conventional solid state drive stores a fixed integer number of host logical blocks in each page of non-volatile memory. The storage efficiency problem occurs when the user data size or usable size of each page of the non-volatile memory is not fixed. The architecture for the variable size flash translation layer within the solid state drive is hardware intensive. The page header is used to identify when user data is stored among multiple read units within a page of a solid state drive, and extracting the data involves first reading and parsing the page header.

The present invention relates to a method of using a variable size flash translation layer. Step (A) receives a read request to read data corresponding to a logical block address from the non-volatile memory. Step (B) is a specific entry in the map to obtain (i) the physical address of a specific page of non-volatile memory, (ii) the offset of the specific page relative to previously stored compressed data, and (iii) the length of the compressed data. read the A specific entry is associated with a logical block address. Step (C) converts the offset and length into (i) the address of a given read unit of a particular page and (ii) the number of read units to be read. Step (D) reads the maximum number of read units from a specific page, starting with a predetermined read unit. Offset and granularity are smaller than read units.

Embodiments of the present invention will be apparent from the following detailed description and appended claims and drawings.
1 is an illustration of selected details of one embodiment of mapping logical block addresses to fixed size regions within a flash page.
2 is an illustration of selected details of one embodiment of mapping logical block addresses to variable size regions that selectively span a flash page.
3 is an illustration of one embodiment of a flash page comprising an integer number of read units.
4 is an illustration of selected details of one embodiment of mapping logical block addresses to variable size regions spanning one or more read units.
5 is an illustration of selected details of one embodiment of a read unit comprising a header and data;
6 is an illustration of selected details of one embodiment of a flash page including a header and data.
7 is an illustration of selected details of one embodiment of a flash page including a header and data in accordance with an embodiment of the present invention.
8 is an illustration of selected details for one embodiment of various types of headers.
9 is an illustration of selected details for one embodiment of a map entry.
10 is an illustration of selected details of one embodiment of various compressed map entries.
11 is a flowchart of reading a non-volatile memory.
12 is an illustration of selected details for one embodiment of a solid state drive controller.

Embodiments of the present invention (i) support a wide range of data sizes, (ii) generate headers with a tiling process, and/or (iii) parse headers with an un-tiling process; and/or (iv) placing all headers at the beginning of each page, (v) placing all data after the header of each page, and/or (vi) unassigned offsets and headers on read unit boundaries. and/or (vii) providing a variable size flash translation layer that may be implemented in one or more integrated circuits and/or associated firmware.

The present invention is directed to a number of methods, including processes, articles of manufacture, devices, systems, compositions of matter, and computer readable storage media (eg, media in optical and/or magnetic mass storage devices such as disks, flash storage). may be implemented in a computer readable medium such as an integrated circuit having non-volatile storage such as The detailed description provides a description of one or more embodiments of the invention that enable improvements in cost, profitability, efficiency, and utility of use in the fields identified above. The Detailed Description includes an introduction that facilitates understanding of the remainder of the Detailed Description. The Introduction includes illustrative embodiments of one or more of the systems, methods, articles of manufacture, and computer readable media in accordance with the concepts described herein. As will be discussed in greater detail, the present invention embraces all possible modifications and variations within the scope of the appended claims.

The FTL (e.g. Flash translation layer) converts the LBA (e.g., the logical block address) of the logical block address space (such as used by the host performing input/output operations to input/output devices) to NAND Flash. It maps to a physical location in a non-volatile memory (eg, NVM), such as a non-volatile memory. Mapping operates on ordered units of one or more logical blocks, called mapping units, such that each mapping unit has a corresponding physical location where the mapping unit's data is stored (if a mapping unit has never been written or trimmed) including the possibility of a NULL physical position). For example, for a 4 KB (eg kilobyte) mapping unit, 8 contiguous (and typically 8 sector aligned) SATA (eg Serial Advanced Technology Attachment) 512 byte sectors are mapped into a single unit. do. In general, a translation table, such as a map, has an entry per mapping unit to store each translation from a logical block address associated with the mapping unit to a physical address in non-volatile memory and/or other control information.

Non-volatile memory, such as NAND flash, provides a writable (or programmable) unit called a flash page. A flash page contains the number of bytes of user (non-error correction code) data and the amount of free space for metadata and ECC (eg, error correction coding), and is typically the smallest writable unit of non-volatile memory. Typical flash page sizes are 8 KB or 16 KB or 32 KB of user data, whereas typical mapping unit sizes are 4 KB or 8 KB. (Although the term "user" data is used for flash pages, some flash pages store "system" data, such as map data and/or checkpoint data. User data generally refers to the non-ECC portion of a flash page. Flash pages are organized into blocks typically 128, 256, or 512 flash pages per block. A block is the smallest size unit that can be erased, and a flash page is erased before a page can be (re)written.

1 , an illustration of selected details of one embodiment of mapping a logical block address to a fixed size region of a flash page is shown. A conventional flash translation layer assumes that the number of user data bytes of a flash page (eg, flash page 100) is a power of two (and/or a multiple of the sector size), and maps the flash page to an integer Divide into units (each shown as data in FIG. 1). For example, for 16 KB of user data and 4 KB mapping unit per flash page, each flash page contains 4 mapping units, and the flash translation layer has the address of each mapping unit (eg, LBA[M: U] 110) to each flash page and maps one of the four mapping units to each flash page. That is, each map entry contains each field as follows:

mapping_unit_within_flash_page [k-1:0] where flash_page_address [n-1:0], flash_page_address refers to a unique flash page in non-volatile memory - mapping_unit_within_flash_page is the 2 ^k mapping unit size portion of each flash page, where k is the total non-volatile memory is fixed for ) refers to one of -. The subpage address 104 is a combination of flash_page_address and mapping_unit_within_flash_page. For sector-based addressing, the lower-order bits of the logical block address (eg, LBA [U-1:0] 111 ) are mapped to multiple sectors within a mapping unit (eg, sector(s) within subpage 113 ). ))) and specify a sub-part.

2 , an illustration of selected details of one embodiment of mapping a logical block address to a variable size region that selectively spans a flash page is shown. A VFTL (e.g., variable-size flash translation layer) conceptually maps (e.g., an address of a mapping unit (e.g., LBA [M:U] 110)) to a variable-size region of one or more flash pages (e.g., Because the data in the mapping unit is compressed before being stored in flash, and/or because, in another example, the mapping unit is written by the host in variable size pieces, such as to an object store). However, providing each map entry with a complete byte address 204 and byte data length 206 makes the map entry larger when compared to a conventional flash translation layer.

A variable size flash translation layer is used in some SSDs (eg solid-state disks). Solid state disk systems are typically designed for high-end client and/or enterprise applications where random access performance constraints are a driving factor in the overall system design. To configure a variable size flash conversion layer for low-end and/or mobile environments, variations can be implemented to configure sequential performance as a driving factor. Embodiments of the present invention provide one or more methods of organizing user data and VFTL metadata to enable less expensive and more efficient low-end and removable non-volatile memory systems where sequential read performance is a dominant constraint.

3 , an illustration of one embodiment of a flash page comprising an integer number of read units is shown. In some embodiments, the variable size flash translation layer performs mapping from the address of the mapping unit to the physical address by mapping to an Epage (eg, ECC page) address, also referred to as a “read unit” address. An Epage (or read unit) is the smallest amount of data that can be read from a non-volatile memory and corrected by an error correction code used to protect the contents of the non-volatile memory. That is, each read unit contains an amount of data and a corresponding ECC check byte protecting that data. In some embodiments, a flash page (such as flash page 100), or in other embodiments a group of flash pages treated as a unit for the purpose of writing, is divided into an integer number of read units as illustrated in FIG. do.

In various embodiments, the number of read units per flash page is allowed to vary. For example, some portions of non-volatile memory use stronger error-correcting codes than others (which use more bytes in flash pages for error-correcting coding), fewer read units per read unit and/or more There is less data available. In another example, the number of read units per flash page changes as the non-volatile memory is used, so that program/erase cycles tend to weaken the non-volatile memory and thus become stronger as the non-volatile memory becomes more used (wearable). This results in an error correction code.

According to various embodiments, the error correction code used may include an RS (eg, Reed-Solomon) code; BCH (eg, Bose Chaudhuri Hocquenghem) codes; turbo code; LDPC (eg, low-density parity-check) codes; polarity code; non-binary code; RAID (eg redundant array of inexpensive/independent disk) codes; erasure code; any other error correction code; one or more of any combination of the foregoing including configuration, connection, and interleaving. Typical codeword sizes range from 512 bytes (plus ECC bytes) to 2176 bytes (plus ECC bytes). A typical number of ECC bytes ranges from just a few bytes to hundreds of bytes.

4 , an illustration of selected details of one embodiment of mapping a logical block address to a variable size region spanning one or more read units is shown. In some embodiments, VFTL mapping is a variable size (eg, compressed) mapping unit's address (eg, LBA[M:U] 110 ) to read unit address 404 and span (eg, read unit's address). number) 406 to the number of read units represented by each entry in the map. The read unit referenced by one of the map entries is the number of read units that traverse one or more (logically and/or physically) sequential flash pages, eg, optionally and/or optionally flash page boundaries. Entries in the map alone are generally not sufficient to locate the associated data (since the entry only refers to the read unit, not the location of the data within the read unit), and additional information (such as headers) within the referenced read unit is not sufficient to locate the associated data. It is used to accurately position the data.

In some embodiments, data is written to a flash page in a manner that is striped across multiple dies of non-volatile memory. Striping write data across multiple dies enables greater write bandwidth by only writing flash pages to a given die once per stripe. A stripe of blocks across multiple dies is referred to as a redundancy block because in further embodiments and/or usage scenarios redundancy such as RAID is added onto the redundancy block using, for example, one redundancy die. In various embodiments, some blocks of non-volatile memory are defective and are skipped upon write, so that the striping sometimes has a hole through which one of the dies is skipped (rather than writing a bad block into a flash page). In such an embodiment, "sequential" flash pages are sequential in a logical order determined by the order in which the flash pages are written.

5 , an illustration of selected details of one embodiment of a read unit comprising a header and data is shown. In various embodiments, the mapping illustrated in FIG. 4 generates criteria for locating variable size data within the read unit. As illustrated in FIG. 5 , each read unit (eg, read units 500 and 510 ) has one header 501 , which typically includes variable size data “tiling” into one or more read units. "(ie, densely packed with no wasted space), so it is written by the hardware. The header is typically interpreted by other hardware to extract variable size data when the non-volatile memory is read. Variable size data is located by respective offsets and lengths in one of the headers with matching logical block addresses, the data optionally and/or optionally illustrated by read units ("data, start" and "data, continue") as exemplified by the variable size data being

In various embodiments, the header is also used as part of reuse (eg, garbage collection) - including a logical block address (or equivalently, a mapping unit address) in the header means finding variable size data in a read unit. If the variable size data is still valid or overwritten inside (look up the logical block address in the map and the map is updated to still refer to the physical address of a particular read unit, or to refer to another one of the pindog units) ) provides a way to determine when a particular one of the read units is to be read.

In some embodiments, dedicated hardware that extracts data from the read unit based on logical block addresses is implemented to operate with high efficiency for random reads. Dedicated hardware parses the header in one or more read units to find one of the headers with a given logical block address, and then uses the respective length and offset to extract the associated variable size data. However, hardware-based solutions are expensive (in silicon area and power). For low-end and/or mobile environments where sequential performance is more important than random, the change is implemented in a variable size flash translation layer to reduce silicon area, save power, and achieve high sequential throughput.

In some embodiments, the SRO-VFTL (eg, sequential-read-optimized variable-size flash translation layer) flashes the data without any gaps to the header in the data (or, in some embodiments, for the purpose of writing) (groups of flash pages treated as units for In a further embodiment, the header is not used dynamically to access data (as in some variable size flash translation layers), but is only used for reuse and recovery. Instead, the entries in the map contain complete information used to discover variable size (eg, compressed) data of flash pages. Separating the header and data into different parts of a flash page includes a read unit containing only the header, a read unit containing a mixture of header and data (but only one such read unit per flash pager), and a read unit containing only data causes

Although configured for sequential read throughput at low cost, the sequential read optimized variable size flash transformation layer provides It can perform relatively well on other metrics. However, the removal of hardware aids functions such as VFTL style data tiling by header in each read unit which places a heavy burden on the control processor.

6 , an illustration of a first embodiment of an SRO-VFTL flash page is shown. Referring to Figure 7, an illustration of a second embodiment of an SRO-VFTL flash page is shown in accordance with an embodiment of the present invention. The difference between the embodiments of Figures 6 and 7 is whether the continuation data from the previous flash page 640 is before or after the header. Various embodiments and arrangements of data within a flash page are contemplated.

According to various embodiments, the flash page includes one or more of the following:

- a master header 610, optionally and/or optionally a redundancy block header 620 (e.g., a header added to the first page of each block within the redundancy block), and zero or more additional packing headers 630 header containing . Every flash page has at least a count of the number of headers and pointers below where the data (associated with the header) begins in the flash page. In some embodiments, headers may be byte aligned, but only 6 bytes each (eg, B). The header may include, but is not limited to, a data header, an epoch header, and padding. The data header uses the mapping unit address and length. The offset is implicit because all data is packed contiguously.

- optionally and/or optionally continuous data from a previous flash page (part of the variable size data of the mapping unit) 640 .

- packed (eg optionally and/or optionally compressed) data of one or more mapping units 650 filling the flash page, optionally and/or optionally continuing in a subsequent flash page.

- optional padding at the end of the flash page (included in 650). In various embodiments, it is possible that the data is byte packed (eg, no holes), but is padded at the end of the flash page if highly compressed (eg, very many headers). Padding may occur for example (i) because the last variable-size piece of data added to the flash page is left with fewer unused bytes than the size of the header (unless a new header can be added to begin another variable-size piece of data) and (ii) optionally and/or optionally, the specified number of headers per flash page is exceeded (the specified number of mapping units stored in the flash page is limited by the specified number of headers and limited by the size of the data in the mapping unit) otherwise) is used.

In some embodiments, recovery and/or reuse (eg, garbage collection) by the sequential read optimization variable size flash translation layer may advantageously read, error correct, and/or inspect only the header portion of each flash page. However, not all read units are capable of doing so, as in out-of-order read optimization variable size flash translation layers. If reuse determines that the data in the flash page can be rewritten, that data can also be read and error corrected. In some embodiments, the entire flash page is read for reuse, but only the header portion is error corrected until a determination is made that some data in the flash page should be reused.

In various embodiments, the number of headers per flash page is limited to constrain the number of read units per flash page that can be read to ensure that all headers are read from non-volatile memory. In the embodiment of Figure 6, only a sufficient number of read units are read to contain the maximum number of headers. In the embodiment of FIG. 7 , an additional number of read units are read to process the maximum size of data completed from the previous flash page (eg, contiguous data 640 ). However, since the embodiment of Figure 7 is determined based on the number of bytes of user (non-error correcting code) data in the previous flash page, and the offset and length of each of the associated map entries, the number of bytes at the completion of the data is determined based on the number of bytes. Allows the read unit to access the completion of data from the previous flash page to be determined from the associated map entry. In addition, only headers before completion of data are optional redundancy block headers (which only exist in known flash pages, such as the first page in each block) and master headers (which are always present in each flash page). In the embodiment of Figure 6, it is assumed that there is a maximum number of headers (or the entire flash page is read) in order to read the completion of the data without having to access the non-volatile memory twice.

In some embodiments, the sequential read optimized variable size flash transform layer uses a single level map with multiple map entries. In another embodiment, the sequential read optimized variable size flash translation layer is a first level map (eg, SLM) pointing to a second level map (eg, SLM) page. FLM) using a multi-level map, such as a two level map, each of the second level map pages including a plurality of leaf level map entries. In a further embodiment, the multi-level map has more than two levels, such as three levels. In some embodiments and/or usage scenarios, the use of a multi-level map allows only the relevant (eg, in use) portion of the map to be stored in local (eg, on-chip) memory (eg, cache). to reduce the cost of maintaining the map. For example, if a typical usage pattern has a logical block address space of 1 gigabyte (eg, GB) active at any point in time, then the portion of the map sufficient to access the active 1 GB portion of the logical block address space. only stored locally for quick access as opposed to being stored in non-volatile memory. External references of the active portion of the logical block address space fetch requested portions of one or more levels of the multi-level map from non-volatile memory, optionally and/or optionally replacing other locally stored portions of the map.

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

Referring to FIG. 8 , an illustration of details of one embodiment for various types of headers is shown. In the example of Figure 8, the header is formatted for each of 6 bytes. According to various embodiments, the various types of headers are one of the following: a whole of the same size; optionally and/or optionally different sizes; each inclusion of each field specifying the size of the header; change in size of different flash pages; and any combination of the foregoing.

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 as the data header appears. In further embodiments and/or usage scenarios, if only a flash page has the remaining space for a data header, then all of the associated data starts in a subsequent flash page.

- A map header, such as an SLM (eg second-level map) header 820 . The second level map header contains a FLMI (eg, first-level map index) that indicates which second level map pages are being stored (such as for second level map reuse and/or recovery).

Log/Checkpoint Header (820). The log/checkpoint header marks data used for reuse, recovery, error handling, debugging, or other special conditions.

The epoch header 830 is used as part of the recovery to associate the data with the corresponding map/checkpoint information. Typically, there is at least one epoch header per flash page.

- The master header 870 is used once per flash page to provide information about the number of headers in the flash page and when non-header data starts within the flash page. Various techniques determine the beginning of non-header data, as illustrated in the embodiments of FIGS. 6 and 7 .

- The redundancy block header 880 is used for a specific flash page, such as the first flash page in each block within the redundancy block.

- Other types of headers 840, such as padding headers, checkpoint headers supporting larger lengths, and the like.

In some embodiments, some headers include a type field that provides headers of multiple subtypes. In various embodiments, some headers include a length (LEN) field that contains the length of data associated with the header. In another embodiment, rather than a LEN field, some headers include an OFFSET(offset) field (not shown) that includes an offset (in a flash page) at the end of data associated with the header. (If the last piece of variable size piece of data spans a flash page, OFFSET is either an offset in a subsequent flash page or multiple bytes in a subsequent flash page.) Only one of the LEN or offset fields is usually a variable size piece of data. With the non-discarded space packed, the start and end positions of each of the variable size pieces of data in the flash page are the first variable size piece of data in the flash page (eg, immediately after the head as in FIG. 7 ). is implemented as implied by the starting position of , and the list of LEN or OFFSET fields.

Referring to FIG. 9 , an illustration of selected details for one embodiment of a map entry 900 is shown. According to various embodiments, a map entry may include one or more of the following:

- physical flash page address,

- the offset of the flash page for variable size data items;

- the length of the variable size data item, and

- Other control information.

In some embodiments, the length is encoded, for example, by offsetting a value of zero to correspond to a specified minimum length. In a further embodiment, data that is compressed to be less than the specified minimum length is padded to be at least the specified minimum length in size.

In various embodiments, the SRO-VFTL map entry is larger than the VFTL map entry because the SRO-VFTL map entry stores the full offset and byte length of the corresponding data. It may be advantageous to reduce the size of a map entry when stored in non-volatile memory. In typical use, data is read and written sequentially, often by some unit greater than one and/or an average number of consecutive mapping units, and a map entry compression format that takes advantage of the sequential nature of writing implements and produces high map compression ratios. relatively cheap to do The compression of map entries is further aided by sequential write data going to the same flash page until the boundary of the flash page is crossed.

Referring to FIG. 10 , an illustration of selected details of one embodiment of various compressed map entries is shown. The various map entries are uncompressed 1010, have the same flash page address as the previous map entry (1020), have the same flash page address as the previous map entry and start at an offset where the previous data ends (1030), and the previous map having the same flash page address as the entry, starting at the offset where the previous data ends, and having the same length as the previous map entry (1040).

In some embodiments with multi-level maps, the cache is maintained with lower-level (such as leaf-level) map pages. Cached map pages are in uncompressed form, providing fast access by the processor. When a map page is moved to a cache (eg, from non-volatile memory or DRAM (eg, dynamic random access memory)), the map page is not compressed. When a map page is flushed from the cache (as due to being modified), the map page is compressed for storage (as in non-volatile memory). According to various embodiments in which DRAM is used to reduce latency by storing some or all of the map pages in the dynamic random access memory, the map pages in the dynamic random access memory are stored in one or more of the following: compressed form; uncompressed form; optionally in compressed or uncompressed form; and an indirection table used to access compressed versions of map pages in dynamic random access memory.

In some embodiments, the host write data of the host write command is optionally or optionally compressed as the host write data arrives and is stored in a FIFO (eg, first-in-first-out) local (such as on-chip) memory. ) is stored in the same way. For example, in some embodiments, host write data may include firmware data structures, flash statistics, portions of a map, such as a cache, that maintain one or more page maps, read data from non-volatile memory including reuse read data, non-volatile It is stored in the UBUF (eg, the unified buffer of FIG. 12 ), along with headers, firmware codes, and other uses of data to be written to memory. In other embodiments, one or more dedicated memories are used for various local storage criteria of the solid state drive.

For each mapping unit of data arriving from the host, the control processor of the solid-state drive (eg, the central processing unit (CPU) of FIG. 12 ) is informed of one or more of the following: each mapping unit address, each , and/or the respective length of each mapping unit to a variable size (eg, compressed) of host data. The control processor is enabled to determine the order of writing of the flash pages, and the total number of non-ECC bytes available for each flash page. According to the total number of non-ECC bytes available in a given one of the flash pages, the control processor is enabled to determine the amount of header and the amount of data placed in the given flash page. For example, the control processor accumulates a header for a given flash page (tracking the number of bytes in the header used so far), and writes variable size data in the mapping unit and header to the given flash until the given flash page is full. Add them to the page in turn. When a given flash page is full, the last part of the data for the last mapping unit of the mapping units added to the given flash page is likely not to fit in the given flash page, and is used as the data completion part of subsequent pages of the flash page; Reduces the total number of non-ECC bytes available for subsequent flash pages for new headers and data.

At a particular point in time, one or more flash pages are enabled to be filled with host write data, and one or more flash pages are enabled to be filled with reused data. For example, at least two bands (eg, a redundancy block in a series such as FIFO) may be populated, one band having "hot" data (eg, fresh from the host) and the other band being "cool" "Has data (eg, reused). Continuing the example, in various embodiments, host write data is enabled to be directed to one of the hot or cool bands, and reused data is enabled to be directed to either the hot or cool band.

The control processor is enabled to translate a series of respective mapping unit addresses, local memory addresses and lengths into one or more of the following: a series of heads to be written to the flash pages as header portions of the flash pages; a user data portion of the flash page comprising at least a portion of data of at least one mapping unit, a first starting address and a first length of a sequential portion of a local memory to be written to the flash page as user data of the flash page; a user data completion portion comprising a second starting address and a second length of a sequential portion of a local memory to be written to a subsequent flash page as a user data completion portion of a subsequent flash page, one mapping unit or a portion of empty data; The number of zero or more padding bytes to be written to the flash page - the padding bytes are used, for example if the user data completion part is empty or the flash page is not filled - . Advantageously, the control processor simply converts the series of respective mapping unit addresses, local memory addresses and lengths into a series of headers by reformatting, and the flash pages (series headers, the complete part of the previous flash page, the user data part) , and any padding bytes) are enabled to generate a small number of DMA (eg, direct memory access) commands that transfer the portion to non-volatile memory.

In various embodiments, compression of host write data is optionally and/or selectively enabled. In a first example, the information in the host write command selectively enables compression. In a second example, compression is selectively enabled as a function of the logical block address of the host write command. In a third example, compression is selectively disabled if compression of the host write data has not reduced the size of the host write data. If compression is not enabled, the host write data is stored uncompressed. According to various embodiments, an entry in the map indicates whether the corresponding data is compressed or uncompressed by one or more of the following: each bit in each entry of the map; and/or the value of the length stored in each map entry. For example, a length of 4 KB in a map entry indicates that the associated data of the map entry is uncompressed, whereas a length of less than 4 KB indicates that the associated data is compressed.

In some embodiments, the data selects a redundancy block to be reused, reads the flash pages of the redundancy block in the order in which the flash pages were written, processes only the read unit containing the header of the flash page, and whether the data is still valid; and by looking up the logical block address (or equivalent mapping unit address) of each header that is the data in the map to see if the data still validly constitutes an appropriate new header and DMA instruction that gathers the data to be reused as part of a new flash page. is reused Then, a new flash page is written to non-volatile memory.

Referring to FIG. 11 , an example of a flowchart 1100 for reading a non-volatile memory is shown. In contrast to the out-of-order read optimal variable size flash translation layer, the header within the read unit (or within the flash page) is not used to extract read data. Both the out-of-order read optimized variable size flash translation layer and the out-of-order read optimized variable size flash translation layer are advantageously enabled to access variable size data and enabled to access only the read unit containing the desired read data.

In some embodiments, in response to receiving a read command from the host comprising the logical block address (step 1110), the control processor and/or the various hardware units may perform one or more of the following:

- converting the logical block address into a mapping unit address (step 1114);

- looking up the mapping unit address in a map comprising a plurality of map entries to determine an associated one of the map entries (step 1118);

- extracting each flash page address of the associated map entry (step 1122) and determining whether the associated flash page is in the flash page cache or read from non-volatile memory (step 1130);

- extracting each offset and length from the associated map entry, and according to each offset and length determining (step 1126):

- a. the number of multiple read units accessed in the associated flash page;

- b. the read unit offset and the total read unit length of the flash page of the read unit accessed, and

- c. a DMA instruction for extracting and processing (eg, decompressing) data associated with a mapping unit address from a decoded version of an accessed read unit;

- in response to determining that the associated flash page is not in the flash page cache, read an accessed read unit of the associated flash page from the non-volatile memory (step 1134), and decode an error correction on the accessed read unit to generate data performing (step 1138);

- extracting the associated data from the corrected data according to the respective offset and length of the associated map entry, and decompressing the extracted data (step 1142);

- providing the decompressed data to the host in response to the read command (step 1146).

Typically for random reads, the number of read units that access in an associated flash page to read associated data is less than all of the read units in the associated flash page. In addition, as the associated data is scaled variable, the number of read units accessing in the associated flash page for a first read instruction referencing a first logical block address increases with respect to a second read instruction referencing a second logical block address. different from the number of read units accessed in the associated flash page, and the second logical block address is different from the first logical block address. In some embodiments, only the number of read units accessing in the associated flash page is read from the associated flash page. That is, only those of the reading unit containing a portion of the associated data are read to access the associated data.

In some embodiments and/or usage scenarios, a particular one of the read units includes at least some of the data associated with a first logical block address and at least some of the data associated with a second different logical block address.

Referring to FIG. 12 , an illustration of selected details for one embodiment of a solid state drive controller 1200 is shown. In some embodiments, the solid state drive controller 1200 is enabled to implement a sequential read optimized variable size flash translation layer. In various embodiments, the controller 1200 may be implemented with one or more integrated circuits.

12 , a HIF (eg host interface) such as SerDes (eg serialization-deserialization) receives commands, such as read and write commands, through an input/output receiver, and write data , and transmits read data. Instructions are sent to the CPU via shared memory (eg OpRAM). The CPU interprets the commands and controls other parts of the SSD controller via shared memory. For example, the CPU communicates DMA commands to and from various datapath transmit and receive units, such as a host receive datapath (e.g. HDRx) or flash transmit datapath (e.g. FDTx), via shared memory. receive a response

Record data from the host interface is transferred to the UBUF (eg unified buffer) via the host receive data path (eg HDRx). In various embodiments, the host receive datapath includes logic to optionally and/or selectively compress and/or encrypt the host write data. Optionally and/or optionally compressed and/or encrypted host write data is then transferred from the integrated buffer via a flash transmit datapath (eg FDTx) to non-volatile memory and GAFI (eg generic flash interface). is sent In various embodiments, the flash transmit datapath includes logic to perform encryption and/or scrambling and/or error correction encoding. In response to a host read command, data is read from the non-volatile memory via GAFI (eg, generic flash interface) and sent to the integrated buffer via a flash receive datapath (eg, FDRx). In various embodiments, the flash receive datapath incorporates error correction decoding and/or decoding and/or descrambling. In another embodiment, a separate error correction decoder (eg, LDPC-D implementing the LDPC code) is enabled to operate on “raw” data stored in the unified buffer by the flash receive datapath. The decoded read data from the integrated buffer is then sent to the host interface via a host transmit datapath (eg, HDTx). In various embodiments, the host transmit datapath includes logic to optionally and/or selectively encrypt and/or decompress the decoded read data. In some embodiments, RAID-like and RASP (eg, soft-decision processing units) provide additional protection for host write data and/or system data stored in non-volatile memory and/or use with LDPC-D. It is enabled to create redundancy, such as RAID, to perform soft decision processing operations for the purpose.

According to various embodiments, any operation of the control processor is performed by any of one or more CPUs, one or more hardware units, and/or any combination of the foregoing. For example, for writing, the conversion of a series of each mapping unit address, local memory address and length to a header series of each mapping unit address, local memory address and length equals the format of the series header. and/or supported by hardware provisioning in a similar format.

According to various embodiments, a solid state drive controller coupled to non-volatile memory is enabled to use one or more of the following: a conventional flash translation layer; variable size flash conversion layer; sequential read optimization variable size flash translation layer; any combination of the foregoing in different physical portions of non-volatile memory; any combination of the foregoing in different logical portions of the logical address space of the SSD controller; raw physical access to non-volatile memory; and any combination of the preceding under the control of a host coupled to the SSD controller.

According to various embodiments, the host write data is optionally encrypted before being written to the non-volatile memory and decrypted after being read from the non-volatile memory. In a further embodiment, encryption occurs after compression of the host write data, and decryption occurs before decompression of the data being read back to the host.

Although exemplary embodiments used solid state drives, the techniques described herein are generally applicable to other input/output devices and/or data storage devices such as hard disk drives.

The following is a collection of example embodiments that provides an additional description of various embodiment types consistent with the concepts described herein, including at least some explicitly enumerated example combinations (eg, ECs); Examples are not meant to be mutually exclusive, exhaustive, or limiting; The present invention is not limited to these exemplary embodiments, but rather covers all possible modifications and variations within the scope of the published claims and their equivalents.

Method EC1 includes receiving, at the input/output device and via a host to the input/output device interface, a read request to read data corresponding to a logical block address of the read request from a non-volatile memory of the input/output device and, in response to receiving the read request, a particular page of previously stored compressed data in response to writing data corresponding to a physical address and a logical block address of the particular page of the plurality of pages of the non-volatile memory. reading a specific map entry of a plurality of entries of a map, the specific map entry being associated with a logical block address of a read request, to obtain an offset of converting the offset of the particular page and the length of bytes of compressed data into the address of a first read unit of a plurality of read units of the particular page and the number of read units to be read from the particular page; The steps of reading only the number, and performing error correction decoding on each of the reading units read from the specific page to obtain corrected data, and the offset of the specific page with respect to the compressed data and the length of the bytes of the compressed data extracting compressed data from the corrected data, decompressing the compressed data to generate return data, and returning the return data to a host.

Method EC2 includes receiving, at the input/output device and via a host to the input/output device interface, a read request to read data corresponding to a logical block address of the read request from a non-volatile memory of the input/output device and, in response to receiving the read request, within the specified page for previously stored compressed data in response to writing data corresponding to the physical address and the logical block address of the specific page of the plurality of pages of the non-volatile memory. reading a specific map entry of a plurality of entries of a map, the specific map entry being associated with a logical block address of a read request, to obtain an offset and a length in bytes of the compressed data; converting the offset of the specific page and the length of bytes of compressed data into the address of a first read unit of a plurality of read units within the specific page and the number of read units to be read from the specific page; reading a number of read units less than all read units; extracting the compressed data from the corrected data according to the length of bytes of the compressed data; decompressing the compressed data to generate return data; and returning the return data to a host.

Method EC1 or EC2, wherein the number of read units to be read is less than all of the read units of a particular page (EC3).

EC1 or EC2, wherein at least a portion of the compressed data is one of a subsequent page of a page of non-volatile memory according to the byte length of the compressed data combined with the offset of the particular page relative to the compressed data and the amount of user data of the particular page. The method (EC4) further comprising determining what is in the above reading unit.

The EC4, wherein in response to an update of the total redundant data on the second processing node, each local redundancy calculation unit of the second processing node stores on at least some of the respective disks of the second processing node an update of the total redundant data. A method enabled to compute the second redundant data according to the data of EC5.

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

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

EC1 or EC2, comprising: receiving, at the input/output device and via a host to the input/output device interface, a write request to write data corresponding to a logical block address; in response to receiving the write request; , compressing the data corresponding to the logical block address to form compressed write data smaller than the data corresponding to the logical block address, and writing at least a first portion of the compressed write data to a specific page; The method (EC8) further comprising storing in the specific entry the physical address of the specific page, the offset of the specific page relative to the compressed write data, and the length in bytes of the compressed write data.

The method of EC8, further comprising: in response to receiving a request to write data, writing a header to a specific page, the header comprising a logical block address of the request and a length in bytes of compressed data (EC9).

The method of EC1 or EC2, wherein the logical block address is a first address of a plurality of logical block addresses, and at least one read unit of the number of read units includes at least a portion of data corresponding to a different address of the logical block addresses. (EC10).

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

The method EC12 includes receiving, at the input/output device and via a host to the input/output device interface, a read request to read data corresponding to a logical block address of the read request from a non-volatile memory of the input/output device. and, in response to receiving the read request, of a specific page of previously stored variable size data in response to writing data corresponding to a physical address and a logical block address of the specific page among the plurality of pages of the non-volatile memory. reading a specific map entry of a plurality of entries of a map, the specific map entry being associated with a logical block address of a read request, to obtain an offset and a length in bytes of the variable size data; converting the offset of the specific page and the length of bytes of variable size data into the address of a first read unit among a plurality of read units of the specific page and the number of read units to be read from the specific page; and performing error correction decoding on each of the reading units read from the specific page to obtain corrected data, according to the offset of the specific page for the variable size data and the length of the bytes of the variable size data. extracting variable size data from the corrected data; and returning the extracted data to a host.

EC1 or EC22, comprising the steps of: receiving, at an input/output device and via a host to an input/output device interface, a write request to write a variable size address corresponding to a logical block address and a size of variable size data; in response to receiving the request, writing at least a first portion of the variable-size data to the particular page, and in the particular entry, the physical address of the particular page, the offset of the particular page to the variable-size data, and the variable-size data The method (EC13) further comprising the step of storing the length of the bytes of variable size data according to the size of .

In some embodiments, a hard disk drive or solid state disk controller, input/output of a multi-node storage device or part(s) thereof, eg, an input/output device enabled for interworking with a processor (such as a CPU) all or part of the operations performed by the controller (such as a RAID on chip die) and parts of the processor, microprocessor, system on chip, application specific integrated circuit, hardware accelerometer, or other circuitry that provides all or part of the operation. Various combinations are specified by specifications compatible with processing by the computer system. The specification conforms to various technologies such as hardware description language, circuit description, netlist description, mask technology, or layout technology. Exemplary techniques include, but are not limited to, Verilog, VHDL, SPICE, SPICE variants such as PSpice, IBIS, LEF, DEF, GDS-II, OASIS, or other techniques. In various embodiments, processing includes any combination of interpretation, compilation, simulation, and synthesis to create, verify, or specify logic and/or circuitry suitable for inclusion on one or more integrated circuits. Each integrated circuit according to various embodiments is designable and/or manufacturable according to various technologies. Technologies include programmable technologies (such as field or mask programmable gate array integrated circuits), semi-custom technologies (such as fully or partially cell-based integrated circuits), and full-custom technologies (such as substantive (such as specialized integrated circuits), any combination thereof, or any other technology compatible with the design and/or manufacture of integrated circuits.

In some embodiments, various combinations of all or some of the operations as described by a computer readable medium having stored thereon a set of instructions may be effected by execution and/or interpretation of one or more program instructions in one or more source and/or script languages. It is performed by interpretation and/or compilation of statements, or by execution of binary instructions generated by compiling, transforming, and/or interpreting information expressed in programming and/or scripting language statements. Statements are compatible with any standard programming or scripting language (such as C, C++, Fortran, Pascal, Ada, Java, VBscript, and Shell). One or more of program instructions, language statements, or binary instructions are optionally stored on one or more computer-readable storage media elements. In various embodiments, some, all, or various portions of program instructions are implemented as one or more functions, routines, subroutines, inline routines, procedures, macros, or portions thereof.

Certain choices have been made for convenience only in the preparation of the text and drawings, and unless indicated to the contrary, the choices should not be construed as conveying additional information pertaining to the structure or operation of the described embodiments. Examples of selection are specific organizations or assignments of designations used in reference numbers and specific organizations or assignments of element identifiers (eg, callouts or numerical indicators) used to identify and reference features and elements of embodiments. including, but not limited to.

The word "comprises" or "comprising" is specifically intended to be interpreted as an idea describing a logical set of open scope and is not meant to convey a physical containment unless the word "in" is explicitly followed.

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

Many variations in construction, arrangement, and use are possible in accordance with the description and are within the scope of the claims of the published patents. For example, the interconnection and functional unit bit widths, clock rates, and types of technology used are variable for various embodiments in each component block. Names given to interconnects and logic are illustrative only and should not be construed as limiting the concepts described. Flowcharts and Flowcharts The order and arrangement of process, operation, and functional elements vary according to various embodiments. Further, unless specifically stated to the contrary, the ranges of values specified, the maximum and minimum values used, or other specific specifications (such as input/output device description types, and the number of entries or steps in registers and buffers) are merely illustrative of implementations. It is intended as an example, and is expected to track improvements and changes in implementation techniques, and should not be construed as limitations.

Functionally equivalent techniques known in the art can be used instead of those described to implement the various components, subsystems, operations, functions, routines, subroutines, inline routines, procedures, macros, or portions thereof. Many functional aspects of an embodiment are dependent on embodiment-dependent design constraints and technology trends of faster processing (facilitating movement of older functions in hardware to software) and higher density (facilitating movement of older functions in software into hardware). As a function, it is selectively feasible in hardware (eg, generally dedicated circuitry) or in software (eg, via some way of a programmed controller or processor). Specific variations of the various embodiments include partitioning, different form factors and differences in configuration; use of different operating systems and other system software; the use of different interface standards, network protocols, or communication links; use of different coding types; and other variations expected in implementing the concepts described herein depending on the inherent engineering and business constraints of a particular application.

The embodiments have been well described in detail and in environmental contexts beyond the minimal implementation of many aspects of the described embodiments. Those skilled in the art will recognize that some embodiments omit disclosed components or features without changing the underlying collaboration among the remaining elements. Many of the details disclosed are not used 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 are not limited to the concepts described herein.

All such changes in design are impractical changes through the teachings conveyed by the described embodiments. Embodiments described herein are broadly applicable to other computing and networking applications, and are not limited to particular applications and industries of the described embodiments. Accordingly, the present invention should be construed to cover all possible modifications and variations that fall within the scope of the claims of the patent.

The functions performed by the drawings of Figures 1 to 12 include conventional general purpose processors, digital computers, microprocessors, microcontrollers, reduced instruction set computer (RISC) processors, as will be apparent to those skilled in the relevant art(s); A complex instruction set computer (CISC) processor, a single instruction multiple data (SIMD) processor, a signal processor, a central processing unit (CPU), an arithmetic logic unit (ALU), a video digital signal processor (VDSP) and/or according to the teachings herein. may be implemented using one or more of similar computer machines programmed accordingly. Appropriate software, firmware, coding, routines, instructions, opcodes, microcode, and/or program modules may also be installed by skilled programmers based on the teachings herein, as will be apparent to those skilled in the relevant art(s). It can be readily prepared immediately. Software is generally executed from a medium or several media by one or more of a machine-implemented processor.

The present invention also relates to an application specific integrated circuit (ASIC), a platform ASIC, a field programmable gate array (FPGA), a programmable logic device (PLD) arranged as a flip chip module and/or a multi-chip module, as described herein. , complex programmable logic device (CPLD), sea-of-gate (SOG), radio frequency integrated circuit (RFIC), application specific standard product (ASSP), one or more monolithic integrated circuits, one or more chips or dies in the preparation of or by connecting an appropriate network of conventional component circuits, modifications of which will be readily apparent to those skilled in the art(s).

Accordingly, the present invention also includes a computer product, which may be a storage medium or media and/or a transmission medium or media comprising instructions that may be used to program a machine to perform one or more processes or methods according to the present invention. can do. Execution of instructions embodied in a computer product by a machine, in conjunction with operation of peripheral circuitry, converts input data into one or more files on a storage medium and/or one or more output signals representing physical objects or entities, such as audio and/or visual representations. can be converted The storage medium includes any type of disk including floppy disks, hard drives, magnetic disks, optical disks, CD-ROMs, DVDs and magneto-optical disks and read-only memory (ROM), random access memory (RAM), EPROM ( circuits such as erasable programmable ROM), electrically erasable programmable ROM (EEPROM), ultra-violet erasable programmable ROM (WPROM), flash memory, magnetic cards, optical cards, and/or any type of medium suitable for storing electronic instructions. may include, but is not limited to.

Elements of the invention may form part or all of one or more devices, units, components, systems, machines and/or devices. Devices include servers, workstations, storage array controllers, storage systems, personal computers, laptop computers, notebook computers, palm computers, personal digital assistants, portable electronic devices, battery power supplies, set-top boxes, encoders, decoders, transcoders, Compressors, decompressors, preprocessors, postprocessors, transmitters, receivers, transceivers, cryptographic circuits, cell phones, digital cameras, positioning and/or navigation systems, medical devices, heads-up displays, wireless devices, audio recordings, audio storage and/or audio playback devices, video recording, video storage and/or video playback devices, gaming platforms, peripherals and/or multi-chip modules. Those skilled in the relevant art(s) will appreciate that elements of the present invention may be embodied in other types of devices to meet the criteria of a particular application.

The terms “may” and “generally” when used herein in conjunction with “is(are)” and the verb are meant to convey the intent that the description is exemplary and are intended to be used in the present disclosure. It is intended to be broad enough to encompass both the specific examples presented in this disclosure as well as alternative examples that may be derived on the basis thereof. The terms "may" and "generally" as used herein are not necessarily to be construed to mean the desirability or possibility of omitting the corresponding element.

Although the present invention has been particularly shown and described with reference to embodiments thereof, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the invention.

Claims (20)

A method of using a variable size flash translation layer, comprising:
(A) receiving, in a device, from a host, a read request to read specific data corresponding to a logical block address from a non-volatile memory of the device;
(B) for previously stored compressed data in response to writing (i) a physical address of a specific page of the plurality of pages of the non-volatile memory, and (ii) the compressed data corresponding to the logical block address; reading a particular one of a plurality of entries in a map to obtain an offset of the particular page, and (iii) a length of the compressed data, the particular entry associated with the logical block address;
(C) converting the offset and the length into (i) an address of a read unit of a plurality of read units of the particular page, and (ii) the number of the read units to be read from the particular page; and
(D) starting from the predetermined reading unit and reading the number of the reading units from the specific page.
includes,
wherein the granularity of the offset and the length is less than the size of one of the read units;
How to use a variable size flash transform layer.
The method of claim 1,
performing error correction decoding on each of the read units read from the specific page to generate corrected data; and
extracting the compressed data from the corrected data according to both (i) the offset of the particular page to the compressed data and (ii) the length of the compressed data.
further comprising,
How to use a variable size flash transform layer.
3. The method of claim 2,
decompressing the compressed data to produce return data; and
transmitting the return data to the host
further comprising,
How to use a variable size flash transform layer.
The method of claim 1,
the number of read units to be read is less than all of the read units of the particular page;
How to use a variable size flash transform layer.
The method of claim 1,
at least a portion of the compressed data is determined based on both (i) the offset of the particular page relative to the compressed data and (ii) the length of the compressed data combined with the amount of user data of the particular page. further comprising determining that it is in one or more subsequent read units of a subsequent one of said pages of non-volatile memory.
How to use a variable size flash transform layer.
6. The method of claim 5,
reading the one or more subsequent read units from the subsequent page;
How to use a variable size flash transform layer.
The method of claim 1,
(i) a first page of the pages of the non-volatile memory includes the first number of read units, and (ii) a second page of the pages of the non-volatile memory includes a second number of read units (iii) the first number is different from the second number;
How to use a variable size flash transform layer.
The method of claim 1,
(i) a first one of the pages of the non-volatile memory contains a first amount of user data, and (ii) a second one of the pages of the non-volatile memory contains a second amount of the user data. (iii) the first amount is different from the second amount;
How to use a variable size flash transform layer.
The method of claim 1,
receiving a write request to write the specific data to the non-volatile memory;
compressing the specific data to produce the compressed data that is smaller than the specific data;
writing at least a portion of the compressed data to the specific page; and
storing (i) the physical address of the particular page, (ii) the offset of the particular page relative to the compressed data, and (iii) the length of the compressed data in the particular entry;
further comprising,
How to use a variable size flash transform layer.
10. The method of claim 9,
and writing a header including at least a portion of the logical block address and the length of the write request to the specific page.
How to use a variable size flash transform layer.
The method of claim 1,
(i) the logical block address is one of a plurality of logical block addresses, and (ii) at least one read unit of the number of read units includes at least some of the logical block addresses corresponding to different logical block addresses. containing different data;
How to use a variable size flash transform layer.
The method of claim 1,
at least one read unit of the number of read units comprises (i) one or more headers, and (ii) a portion of the compressed data;
How to use a variable size flash transform layer.
A device using a variable size flash translation layer, comprising:
non-volatile memory; and
Circuit
including,
The circuit is
(i) receiving a read request from the host to read specific data corresponding to a logical block address from the non-volatile memory;
(ii) (a) a physical address of a particular page of the plurality of pages of the non-volatile memory; (b) the previously stored compressed data in response to writing the compressed data corresponding to the logical block address; reading a particular one of a plurality of entries in a map to obtain an offset of a particular page and (c) a length of the compressed data, the particular entry associated with the logical block address;
(iii) converting the offset and the length into (a) an address of a read unit among a plurality of read units of the particular page and (b) the number of the read units to be read from the particular page;
(iv) starting from the predetermined reading unit and reading the number of the reading units from the specific page;
the units of the offset and the length are smaller than the size of one of the read units;
Devices that use a variable size flash translation layer.
14. The method of claim 13,
The circuit is
(i) perform error correction decoding for each of the read units read from the specific page to generate corrected data;
(ii) extracting the compressed data from the corrected data according to both (a) the offset of the particular page relative to the compressed data and (b) the length of the compressed data;
Devices that use a variable size flash translation layer.
15. The method of claim 14,
The circuit is
(i) decompress the compressed data to produce return data;
(ii) further configured to send the return data to the host;
Devices that use a variable size flash translation layer.
14. The method of claim 13,
the number of read units to be read is less than all of the read units of the particular page;
Devices that use a variable size flash translation layer.
14. The method of claim 13,
The circuitry is configured to: based on both (i) the offset of the particular page relative to the compressed data and (ii) the length of the compressed data combined with an amount of user data of the particular page, the compressed data further configured to determine that at least a portion of is in one or more subsequent read units of a subsequent one of the pages of the non-volatile memory;
Devices that use a variable size flash translation layer.
18. The method of claim 17,
wherein the circuitry is further configured to read the one or more subsequent read units from the subsequent page;
Devices that use a variable size flash translation layer.
14. The method of claim 13,
(i) a first page of the pages of the non-volatile memory includes the first number of read units, and (ii) a second page of the pages of the non-volatile memory includes a second number of read units (iii) the first number is different from the second number;
Devices that use a variable size flash translation layer.
14. The method of claim 13,
wherein the device is implemented with one or more integrated circuits,
Devices that use a variable size flash translation layer.

Images