Patent Description:
A storage device, such as a solid-state drive (SSD), may include one or more non-volatile memory devices. The SSD may further include a controller that may manage allocation of data on the memory devices and provide an interface between the storage devices and the host computer system.

<CIT> relates to a Solid State Drive (SSD) which may include flash memory to store data and may support a plurality of device streams. A SSD controller may manage reading and writing data to the flash memory, and may store a submission queue and a chunk-to-stream mapper. A flash translation layer may include a receiver to receive a write command, an LBA mapper to map an LBA to a chunk identifier (ID), stream selection logic to select a stream ID based on the chunk ID, a stream ID adder to add the stream ID to the write command, a queuer to place the chunk ID in the submission queue, and background logic to update the chunk-to-stream mapper after the chunk ID is removed from the submission queue.

<CIT> relates to an interface for enabling a computer device to utilize data property-based data placement inside a nonvolatile memory device comprises: executing a software component at an operating system level in the computer device that monitors update statistics of all data item modifications into the nonvolatile memory device, including one or more of update frequencies for each data item, accumulated update and delete frequencies specific to each file type, and an origin of the data item; storing the update statistics of each of the data items and each of the data item types in a database; and intercepting all operations, including create, write, and update, of performed by applications to all the data items, and automatically assigning a data property identifier to each of the data items based on current update statistics in the database, such that the data items and assigned data property identifiers are transmitted over a memory channel to the non-volatile memory device.

<CIT> relates to subject matter which includes processing file system metadata in host write requests to determine information about future host write operations. The information regarding future host write operations can be used by a device controller to prepare the non-volatile memory for the future host write operations. For example, the device controller may prepare the non-volatile storage device for future sequential host write access patterns or random host write access patterns depending on the content of the file system metadata. The file system metadata may also be usable to determine when it is optimal to perform memory management operations.

<CIT> relates to management of and region selection for writes to non-volatile memory of an SSD, which improves performance, reliability, unit cost, and/or development cost of an SSD. A controller receives and determines characteristics of writes (e.g. by analyzing the write data (<NUM>), the write data source (<NUM>), and/or by receiving a hint (<NUM>)) and selects a region based on the determined characteristics and properties of regions of non-volatile memory. For example, a controller receives writes determined to be read-only data and selects regions of non-volatile memory containing cells that are likely to have write failures. By placing read-only data in write failure prone regions, the likelihood of an error is reduced, thus improving reliability. As another example, a controller receives writes hinted to be uncompressible and selects regions of non-volatile memory containing uncompressible data.

<CIT> relates to employing sequential write stream management to improve the sequential nature of write data placed in a storage such as a solid state drive, notwithstanding intermingling of write commands from various sequential and nonsequential streams from multiple processor nodes in a system. In one embodiment, write data from an identified sequential write stream is placed in a storage area assigned to that particular identified sequential write stream. In another aspect, detected sequential write streams are identified as a function of write velocity of the detected stream.

<CIT> relates to embodiments for data property-based data placement inside a nonvolatile memory device performed by a storage controller of the nonvolatile memory device. In one aspect, the embodiments include: executing a software component on the computer device that detects at least one of an executing application and a hardware device connecting to the computing device; responsive to detecting the at least one executing application and the hardware device, searching, by the software component, a workflow repository to find a predetermined workflow associated with the at least one executing application and the hardware device, wherein the predetermined workflow associates predefined data property identifiers to different types of data items written to the nonvolatile memory device by the executing application or the hardware device; comparing, by the software component, activities of the at least one executing application and the hardware device to the predetermined workflow; and using the predetermined workflow to automatically assign the data property identifiers to the data items used by the application or the hardware device, such that the data items and assigned data property identifiers are transmitted over a channel to the nonvolatile memory device for storage wherein the nonvolatile memory device reads the data property identifiers and identifies which blocks of the nonvolatile memory device to store the corresponding data items, such that the data items having the same data property identifiers are stored in a same block.

<CIT> relates to methods based on a direct transformation of original data to "shaped" data. The disclosed methods may be performed "on-the-fly" and the disclosed methods may utilize an inherent redundancy in compressible data in order to achieve endurance enhancement and error reduction. In a particular example, a method comprises generating a first portion of output data by applying a mapping of input bit sequences to output bit sequences to a first portion of input data, updating the mapping of the input bit sequences to the output bit sequences based on the first portion of the input data to generate an updated mapping, reading a second portion of the input data, and generating a second portion of the output data by applying the updated mapping of the input bit sequences to the output bit sequences to the second portion of the input data.

The present disclosure will be understood more fully from the detailed description given below and from the accompanying drawings of various implementations of the disclosure.

Aspects of the present disclosure are directed to specifying and utilizing write stream attributes in storage write commands that are transmitted by a host system to a storage device controller. The host system may group, into several data streams, the data to be written to the storage device, such that each data stream would contain data items belonging to the same group of associated data (e.g., the data associated with a single data structure, such as a file or a database). Thus, the data items contained by a single data stream may share one or more attributes reflecting anticipated media usage patterns, e.g., the anticipated retention time (also referred to as the "stream temperature") or the workload type. In certain implementations, the data stream may be identified by a dedicated field in each write command transmitted by the host system to the storage device controller. The storage device controller may utilize the stream identifying information in order to optimize the usage of the storage media (e.g., the negative-and (NAND) flash memory), e.g., by placing the data items of the same data stream in a contiguous section of the storage media.

In accordance with one or more aspects of the present disclosure, one or more bits of the stream identifier field of the write command are utilized for specifying one or more data attributes shared by the data items of the data stream. Thus, each write command transmitted by the host system to the storage device controller may not only identify the stream, but also indicate the data attributes which are shared by the data items of the data stream. The storage device controller may utilize the stream identifying information enhanced by the data attributes in order to further optimize the usage of the storage media, e.g., by placing the data items of two or more data streams sharing one or more data attributes in the same or physically proximate sections of the storage media and/or avoiding the placement of two or more data streams having substantially different data attributes in the same or physically proximate sections of the storage media. Such placement strategies may be directed to distributing the programming and erasing cycles uniformly across the media in order to maximize the endurance of the storage media, as explained in more detail herein below.

Thus, aspects of the present disclosure represent significant improvements over various common implementations of storage devices and systems, by enhancing each write command with the data stream attributes in order to further optimize the usage of the storage media. Various aspects of the above referenced methods and systems are described in details herein below by way of examples, rather than by way of limitation.

<FIG> schematically illustrates an example computing environment <NUM> operating in accordance with one or more aspects of the present disclosure. In general, the computing environment <NUM> may include a host system <NUM> that uses the storage device <NUM>. For example, the host system <NUM> may write data to the storage device <NUM> and read data from the storage device <NUM>. The host system <NUM> may be a computing device such as a desktop computer, laptop computer, network server, mobile device, or such computing device that includes a memory and a processing device. The host system <NUM> may include or be coupled to the storage device <NUM> so that the host system <NUM> may read data from or write data to the storage device <NUM>. For example, the host system <NUM> may be coupled to the storage device <NUM> via a physical host interface. Examples of a physical host interface include, but are not limited to, a serial advanced technology attachment (SATA) interface, a peripheral component interconnect express (PCIe) interface, universal serial bus (USB) interface, an NVM Express (NVMe), Fibre Channel, Serial Attached SCSI (SAS), etc. The physical host interface may be used to transmit data between the host system <NUM> and the storage device <NUM>. In an illustrative example, the host system <NUM> may be represented by the computer system <NUM> of <FIG>.

As shown in <FIG>, the storage device <NUM> may include a controller <NUM> and storage media, such as memory devices 112A to 112N. In certain implementations, the memory devices 112A to 112N may be provided by non-volatile memory devices, such as NAND flash memory. Each of the memory devices 112A to 112N may include one or more arrays of memory cells such as single level cells (SLCs), multi-level cells (MLCs), or quad-level cells (QLCs). Each of the memory cells may store bits of data (e.g., data blocks) used by the host system <NUM>. Although non-volatile memory devices such as NAND flash memory are described, the memory devices 112A to 112N may be based on any other type of memory. For example, the memory devices 112A to 112N may be provided by random access memory (RAM), read-only memory (ROM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), phase change memory (PCM), magneto random access memory (MRAM), negative-or (NOR) flash memory, and electrically erasable programmable read-only memory (EEPROM). Furthermore, the memory cells of the memory devices 112A to 112N may be grouped as memory pages or data blocks that may refer to a unit of the memory device used to store data.

The controller <NUM> may communicate with the memory devices 112A to 112N to perform operations including reading data from or writing data to the memory devices 112A-112N. The controller <NUM> may include hardware such as one or more integrated circuits, firmware, or a combination thereof. In operation, the controller <NUM> may receive commands or operations from the host system <NUM> and may convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory devices 112A-112N. In various illustrative examples, the controller <NUM> may be responsible for other operations such as wear leveling, garbage collection, error detection and error-correcting code (ECC), encryption, caching, and address translations between a logical block address and a physical block address that are associated with the memory devices 112A-112N.

In order to implement the systems and methods of the present disclosure, the controller <NUM> may include a data allocation functional component <NUM> that may be employed to allocate the incoming data to particular locations on memory devices 112A-112N. It should be noted that the component designation is of a purely functional nature, i.e., the functions of the data allocation component may be implemented by one or more hardware components and/or firmware modules of the controller <NUM>, as described in more detail herein below. The storage device <NUM> may include additional circuitry or components that are omitted from <FIG> for clarity and conciseness.

<FIG> schematically illustrates a programming model which may be implemented by the host system <NUM> in communication with the storage device controller <NUM> managing one or more memory devices 112A-112N, in accordance with one or more aspects of the present disclosure. As schematically illustrated by <FIG>, the host system may execute one or more applications 210A-210B. In an illustrative example, the application 210A may be in communication with the file system driver <NUM>, which may be running in the kernel space of the host system <NUM> and may be employed for processing certain system calls, such as read and write calls initiated by one or more applications <NUM>, including the application 210A, running in the user space of the host system <NUM>. The file system driver <NUM> may be employed to translate the read, write, and other system calls issued by the application 210A into low-level application programming interface (API) calls to the storage driver <NUM>, which, in turn may communicate to the device controller <NUM> controlling one or more memory devices 112A-112N. The storage driver <NUM> may be running in the kernel mode of the host system and may be employed to process API calls issued by the file system driver <NUM> and/or system calls issued by the application 210B into storage interface commands to be processed by the storage the device controller <NUM> managing one or more memory devices 112A-112N.

In an illustrative example, the storage driver <NUM> may implement a block storage model, in which the data is grouped into blocks of one or more pre-defined sizes and is addressable by a block number. The block storage model may implement "read" and "write" command for storing and retrieving blocks of data. In an illustrative example, the storage driver <NUM> may implement a key-value storage model, in which the data is represented by the "value" component of a key-value pair is addressable by the "key" component of the key-value pair. The key value storage model may implement "put and get" commands, which are functionally similar to the "write" and "read" commands of the block storage model. Thus, the term "data item" as used herein may refer to a data block or to a key-value pair.

The application 210A-210B and/or the storage driver <NUM> executed by the host system <NUM> may group, into several data streams, the data to be written to the memory devices <NUM>, such that the data items belonging to the same data stream would share one or more attributes. In an illustrative example, a data attribute may reflect the anticipated retention time of the data stream (also referred to as the "stream temperature"), such that a "hot" data stream would comprise short-living data items which are likely to be overwritten within a relatively short period of time (e.g., a period of time falling below a pre-defined low threshold), while a "cold" data stream comprise static data items which are not likely to be overwritten for a relatively long period of time (e.g., a period of time exceeding a pre-defined high threshold). In an illustrative example, the data stream temperature may be communicated to the storage driver <NUM> by the application <NUM> which produces the data stream and thus is presumably aware of its anticipated retention time. The data stream temperature may be communicated to the storage driver <NUM>, e.g., via an Input/Output Control (IOCTL) system call. Alternatively, the data stream temperature may be determined by the storage driver <NUM>, which may buffer the incoming data to be written to the memory devices 112A-112N, and may estimate the stream temperature based on the average frequency of overwrite operations requested by the application <NUM> with respect to one or more data items to be written to the memory devices 112A-112N. The storage driver <NUM> may then group the buffered data to be written to the storage device <NUM> into two or more data streams, and may issue stream write commands indicating the data stream temperature to the storage device controller <NUM>, as described in more detail herein below.

In another illustrative example, a data attribute may reflect the workload type of the data stream, e.g., the "log data" attribute indicating that the data represents the logging data related to one or more databases and/or file systems or "user data" attribute indicating that the data represents other (not related to database or file system logs) types of data. The data stream workload type may be communicated to the storage driver <NUM> by the application <NUM> which produces the data stream and thus is presumably aware of its workload type. The data stream workload type may be communicated to the storage driver <NUM>, e.g., via an Input/Output Control (IOCTL) system call. The storage driver may group the data labelled with the "log data" attribute into one or more data streams, and may issue stream write commands indicating the workload type to the storage device controller <NUM>, as described in more detail herein below.

In certain implementations, the data stream may be identified by a dedicated field in each write command transmitted by the host system to the storage device controller. <FIG> schematically illustrates an example structure of the write stream command, in accordance with one or more aspects of the present disclosure. The write stream command <NUM> may include, among other fields, the operation code field <NUM> specifying the command type (e.g., the write stream command). The write stream command <NUM> may further include the flags field <NUM> specifying one or more parameters of the command. The write stream command <NUM> may further include the logical block address (LBA) field <NUM> specifying the LBA of the data being stored on the storage device. The write stream command <NUM> further includes the stream identifier field <NUM> represented by a bit string, which may be interpreted as an unsigned integer value. One or more bits (such as a group of one or more most significant bits or a group of or more least significant bits) of the stream identifier field <NUM> are utilized for specifying one or more data stream attributes <NUM> shared by the data items of the data stream. In an illustrative example, one or more bits of the stream identifier field <NUM> may be utilized for specifying the data stream temperature (e.g., "<NUM>" indicating a cold stream and "<NUM>" indicating a hot stream, or "<NUM>" indicating unknown stream temperature, "<NUM>" indicating a cold stream, "<NUM>" indicating medium stream temperature, and "<NUM>" indicating a hot stream). In an illustrative example, one or more bits of the stream identifier field <NUM> may be utilized for specifying the workload type of the data stream (e.g., "<NUM>" indicating the "log data" workload type and "<NUM>" indicating "user data" workload type). The write stream command <NUM> may include various other fields which are omitted from <FIG> for clarity and conciseness.

Thus, each write command transmitted by the host system to the storage device controller may not only identify the stream, but also indicate the data attributes which are shared by the data items of the data stream. The storage device controller utilizes the stream identifying information enhanced by the data attributes in order to determine storage operation parameters (such as one or more parameters defining the data placement on the storage media) that would optimize the usage of the storage media. The storage device controller may implement one or more wear leveling methods directed to distributing the programming and erasing cycles uniformly across the media. The wear leveling methods implemented by the storage device controller may involve avoiding placing the "hot" data to the physical blocks that have experienced relatively heavy wear. The storage device controller may place the "cold" data and/or move the data that has not been modified for at least a certain period of time (e.g., a period of time exceeding a certain threshold) out of blocks that have experienced a low number of programming/erasing cycles into more heavily worn blocks. This strategy frees up the low-worn blocks for the "hot" data, while reducing the expected wear on the heavily-worn blocks.

In an illustrative example, erasing one or more data items of one data stream may require erasing one or more data items which are stored within the same or physically proximate sections of the storage media. Therefore, placing the data streams having substantially different expected retention time within the same or physically proximate sections of the storage media may result in excessive number of programming and erasing cycles to be performed by the controller on the storage media. Conversely, placing the data streams having similar expected retention time within the same or physically proximate sections of the storage media may result in reducing the number of programming and erasing cycles to be performed by the controller on the storage media. Accordingly, a storage device controller operating in one or more aspects of the present disclosure may implement a data placement strategy which is directed to distributing the programming and erasing cycles uniformly across the media in order to maximize the endurance of the storage media.

<FIG> schematically illustrates an example data placement strategy implemented by the storage device controller operating in accordance with one or more aspects of the present disclosure. In an illustrative example, the storage device controller may place the data items of two or more data streams sharing one or more data attributes (such as the data stream temperature and/or data stream workload type) in the same or physically proximate sections of the storage media. In an illustrative example, "section of the storage media" may be represented by a group of one or more memory cells such as single level cells (SLCs), multi-level cells (MLCs), or quad-level cells (QLCs) of NAND type flash memory. In another illustrative example, "section of the storage media" may be represented by groups of memory units addressable by the same signal (such as a word line or a bit line).

As shown in <FIG>, data streams <NUM> and <NUM>, including data items 410A-410N and 420A-<NUM>, respectively, may share the stream temperature <NUM> (e.g., "H" denoting "hot"). Accordingly, the storage device controller may issue one or more device-level instructions to the data storage devices in order to place the data items of the data streams <NUM> and <NUM>, including, for example, data items 410A, 410B, and 420A, into the same section 450A of the storage media <NUM>.

In another illustrative example, the storage device controller may avoid placing two or more data streams having substantially different data attributes (such as the data stream temperature and/or data stream workload type) in the same or physically proximate sections of the storage media. As shown in <FIG>, the data stream <NUM> including data items 430A-<NUM> may have a stream temperature <NUM> (e.g., "C" denoting "cold") which is different from the stream temperature <NUM> shared by the data streams <NUM> and <NUM>. Accordingly, the storage device controller may issue one or more device-level instructions to the data storage devices in order to place the data items of the data stream <NUM>, including, for example, data items 430A, 430B, and 430C, into the section 450B of the storage media <NUM>.

<FIG> is a flow diagram of an example method <NUM> of determining storage operation parameters based on data stream attributes, in accordance with one or more aspects of the present disclosure. The method <NUM> may be performed by processing logic that may include hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc.), software (e.g., instructions run or executed on a processing device), or a combination thereof. In some embodiments, the method <NUM> may be performed by the storage device controller <NUM> of <FIG>.

As shown in <FIG>, at block <NUM>, the processing logic implementing the method receives, from a host system, a write command specifying a data item to be written to a memory device managed by the storage device controller. The write command further specifies an identifier of a data stream to which the write command belongs. In an illustrative example, the identifier of the data stream is provided by an unsigned integer value. A portion of the identifier of the data stream may encode one or more data attributes shared by the data items of the data stream. In an illustrative example, the data attribute may include a value reflecting an anticipated retention time of the data items of the data stream. In another illustrative example, the data attribute may include a value reflecting a workload type of the data items of the data stream, as described in more detail herein above.

At block <NUM>, the processing logic parses the identifier of the data stream to determine a data attribute shared by data items comprised by the data stream. Parsing the identifier of the data stream involves identifying a bit string of a pre-defined size starting from a pre-defined position within the data stream identifier.

At block <NUM>, the processing logic determines, based on the data attribute, one or more storage operation parameters (such as one or more parameters defining the data placement on the storage media) that would optimize the usage of the storage media, e.g., by uniformly distributing programming cycles across the storage media. In an illustrative example, a storage operation parameter may identify the section of the memory device to be utilized for storing the data item. In another illustrative example, the identified section may be located in a physical proximity of another section, which is used for storing another data stream having the same attribute as the data items being stored, as described in more detail herein above.

At block <NUM>, the processing logic transmits, to the storage device, an instruction specifying the data item and the storage operation parameters, as described in more detail herein above.

<FIG> is a flow diagram of an example method <NUM> of providing data stream attributes within the data stream identifier field of stream write commands, in accordance with one or more aspects of the present disclosure. The method <NUM> may be performed by processing logic that may include hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc.), software (e.g., instructions run or executed on a processing device), or a combination thereof. In some embodiments, the method <NUM> may be performed by the host system <NUM> of <FIG> (e.g., by the storage driver <NUM> of <FIG>).

As shown in <FIG>, at block <NUM>, the processing logic implementing the method may receive a plurality of data items to be written to a storage device. The plurality of data items may be produced by an application running on the host system, as described in more detail herein above with references to <FIG>.

At block <NUM>, the processing logic may group the received data items into one or more data streams, such that the data items contained by a single data stream may share one or more attributes reflecting anticipated media usage patterns, e.g., the anticipated retention time (also referred to as the "stream temperature") or the workload type. In an illustrative example, the processing logic may identify, among the plurality of data items, two or more data items sharing one or more data attributes. Based on the data attribute values, the processing logic may append the identified data items to a newly created or an existing data stream. In an illustrative example, the data attribute may include a value reflecting an anticipated retention time of the data items of the data stream. In another illustrative example, the data attribute may include a value reflecting a workload type of the data items of the data stream, as described in more detail herein above.

At block <NUM>, the processing logic may generate a data stream identifier which includes an encoded form of the data attribute. In an illustrative example, the data stream identifier may be provided by an unsigned integer value, one or more bits of which may be utilized for encoding the data attributes shared by the data items of the data stream. In an illustrative example, the bit string encoding the data attributes may have a pre-defined size and may start from a pre-defined position within the data stream identifier. In an illustrative example, the data attribute may include a value reflecting an anticipated retention time of the data items of the data stream. In another illustrative example, the data attribute may include a value reflecting a workload type of the data items of the data stream, as described in more detail herein above.

At block <NUM>, the processing logic may transmit, to a controller of the storage device, one or more write commands specifying the data comprised by the first data item and the second data item. Each write command may further specify the data stream identifier, the reserved part of which encodes the data attribute.

<FIG> is a block diagram of an example storage device controller <NUM>, which may implement the functionality of the controller <NUM> of <FIG>. As shown in <FIG>, the controller <NUM> may include a host interface circuitry <NUM> to interface with a host system via a physical host interface <NUM>. The host interface circuitry <NUM> may be employed for converting commands received from the host system into device-level instructions. The host interface circuitry <NUM> may be in communication with the host-memory translation circuitry <NUM>, which may be employed for translating host addresses to memory device addresses. For example, the host-memory translation circuitry <NUM> may convert logical block addresses (LBAs) specified by host system read or write operations to commands directed to non-volatile memory units identified by logical unit numbers (LUNs) <NUM>. The host-memory translation circuitry <NUM> may include error detection/correction circuitry, such as exclusive or (XOR) circuitry that may calculate parity information based on information received from the host interface circuitry <NUM>.

The memory management circuitry <NUM> may be coupled to the host-memory translation circuitry <NUM> and the switch <NUM>. The memory management circuitry <NUM> may control various memory management operations including, but not limited to, initialization, wear leveling, garbage collection, reclamation, and/or error detection/correction. The memory management circuitry <NUM> may include block management circuitry <NUM> which may be employed for retrieving data from the volatile memory <NUM> and/or non-volatile memory identified by LUNs <NUM>. For example, the block management circuitry <NUM> may retrieve information such as identifications of valid data blocks, erase counts, and/or other status information of the LUNs <NUM>. The memory management circuitry <NUM> may further include data allocation component <NUM> that may be employed to allocate the incoming data to particular locations on logical units identified by LUNs <NUM>. It should be noted that the component designation is of a purely functional nature, i.e., the functions of the data allocation component may be implemented by one or more hardware components and/or firmware modules of the controller <NUM>, such as the processor <NUM>, which may be employed for implementing at least some of the above-referenced memory management operations.

The switch <NUM> may be coupled to the host-memory translation circuitry <NUM>, the memory management circuitry <NUM>, the non-volatile memory control circuitry <NUM>, and/or the volatile memory control circuitry <NUM>. The switch <NUM> may include and/or be coupled to a number of buffers. For example, the switch <NUM> may include internal static random access memory (SRAM) buffers (ISBs) <NUM>. The switch may be coupled to DRAM buffers <NUM> that are included in the volatile memory <NUM>. In some embodiments, the switch <NUM> may provide an interface between various components of the controller <NUM>.

The non-volatile memory control circuitry <NUM> may store, in one of the buffers (e.g., the ISBs <NUM> or the buffer <NUM>), information corresponding to a received read command. Furthermore, the non-volatile memory control circuitry <NUM> may retrieve the information from one of the buffers and write the information to a logical unit of the non-volatile memory identified by a LUN <NUM>. The logical units identified by LUNs <NUM> may be coupled to the non-volatile memory control circuitry <NUM> by a number of channels. In some embodiments, the number of channels may be controlled collectively by the non-volatile memory control circuitry <NUM>. In some embodiments, each memory channel may be coupled to a discrete channel control circuit <NUM>. A particular channel control circuit <NUM> may control and be coupled to more than one memory unit <NUM> by a single channel.

The non-volatile memory control circuitry <NUM> may include a channel request queue (CRQ) <NUM> that is coupled to each of the channel control circuits <NUM>. Furthermore, each channel control circuit <NUM> may include a memory unit request queue (RQ) <NUM> that is coupled to multiple memory unit command queues (CQs) <NUM>. The CRQ <NUM> may be configured to store commands (e.g., write requests or read requests) shared between channels, the RQ <NUM> may be configured to store commands between the memory units <NUM> on a particular channel, and the CQ <NUM> may be configured to queue a current command and a next command to be executed subsequent to the current command.

The CRQ <NUM> may be configured to receive a command from the switch <NUM> and relay the command to one of the RQs <NUM> (e.g., the RQ <NUM> associated with the channel that is associated with the particular logical unit identified by the LUN <NUM> for which the command is targeted). The RQ <NUM> may be configured to relay a first number of commands for a particular memory unit <NUM> to the CQ <NUM> that is associated with the particular logical unit identified by the LUN <NUM> in an order that the first number of commands were received by the RQ <NUM>. A command pipeline may be structured such that commands to the logical unit move in a particular order (e.g., in the order that they were received by the RQ <NUM>). The RQ <NUM> may be configured to queue a command for a particular logical unit in response to the CQ <NUM> associated with the particular logical unit being full and the CRQ <NUM> may be configured to queue a command for a particular RQ <NUM> in response to the particular RQ <NUM> being full.

The RQ <NUM> may relay a number of commands for different logical units identified by LUNs <NUM> to the CQs <NUM> that are associated with the logical units in an order according to the status of the logical units. For example, the logical unit status may be a ready/busy status. The command pipeline is structured such that the commands between different logical units may move out of order (e.g., in an order that is different from the order in which they were received by the RQ <NUM> according to what is efficient for overall memory operation at the time). For example, the RQ <NUM> may be configured to relay a first one of the second number of commands to a first CQ <NUM> before relaying a second command from the second number of commands to a second CQ <NUM> in response to the status of the different logical unit associated with the second CQ <NUM> being busy, where the first command is received later in time than the second command. The RQ <NUM> may be configured to relay the second command to the second CQ <NUM> in response to the status of the logical unit associated with the second CQ <NUM> being ready (e.g., subsequent to relaying the first command).

In some embodiments, the control circuits for each channel may include discrete error detection/correction circuitry <NUM> (e.g., error correction code (ECC) circuitry), coupled to each channel control circuit <NUM> and/or a number of error detection/correction circuits <NUM> that can be used with more than one channel. The error detection/correction circuitry <NUM> may be configured to apply error correction such as Bose-Chaudhuri-Hocquenghem (BCH) error correction to detect and/or correct errors associated with information stored in the logical unit identified by the LUN <NUM>. The error detection/correction circuitry <NUM> may be configured to provide differing error correction schemes for SLC, MLC, or QLC operations.

<FIG> illustrates an example computer system <NUM> within which a set of instructions, for causing the computer system to perform any one or more of the methodologies discussed herein, may be executed. In an illustrative example, the computer system <NUM> may implement the functions of the host system <NUM> of <FIG>. In alternative implementations, the computer system may be connected (e.g., networked) to other computer systems in a LAN, an intranet, an extranet, and/or the Internet. The computer system may operate in the capacity of a server or a client computer system in client-server network environment, as a peer computer system in a peer-to-peer (or distributed) network environment, or as a server or a client computer system in a cloud computing infrastructure or environment.

The computer system may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, a switch or bridge, or any computer system capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that computer system. Further, while a single computer system is illustrated, the term "computer system" shall also be taken to include any collection of computer system s that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computer system <NUM> includes a processing device <NUM>, a main memory <NUM> (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM)), a static memory <NUM> (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device <NUM>, which communicate with each other via a bus <NUM>. In an illustrative example, the data storage device <NUM> may implement the functions of the storage device <NUM> of <FIG>.

Processing device <NUM> represents one or more general-purpose processing devices such as a microprocessor, a central processing unit, or the like. More particularly, the processing device may be complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processing device <NUM> may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device <NUM> is configured to execute instructions <NUM> for performing the operations and steps discussed herein.

The computer system <NUM> may further include a network interface device <NUM> to communicate over the network <NUM>. The computer system <NUM> also may include a video display unit <NUM> (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device <NUM> (e.g., a keyboard), a cursor control device <NUM> (e.g., a mouse), a graphics processing unit <NUM>, a signal generation device <NUM> (e.g., a speaker), graphics processing unit <NUM>, video processing unit <NUM>, and audio processing unit <NUM>.

The data storage device <NUM> may include computer-readable storage medium <NUM> on which is stored one or more sets of instructions or software <NUM> embodying any one or more of the methodologies or functions described herein. The instructions <NUM> may also reside, completely or at least partially, within the main memory <NUM> and/or within the processing device <NUM> during execution thereof by the computer system <NUM>, the main memory <NUM> and the processing device <NUM> also constituting computer-readable storage media. The computer-readable storage medium <NUM>, data storage device <NUM>, and/or main memory <NUM> may correspond to the storage device <NUM> of <FIG>.

In one implementation, the instructions <NUM> include instructions to implement functionality corresponding to a data allocation component (e.g., data allocation component <NUM> of <FIG>). While the computer-readable storage medium <NUM> is shown in an example implementation to be a single medium, the term "computer-readable storage medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "computer-readable storage medium" shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the computer and that cause the computer to perform any one or more of the methodologies of the present disclosure. The term "computer-readable storage medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical media and magnetic media.

Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as "receiving" or "determining" or "transmitting" or "reflecting" or "specifying" or "identifying" or "providing" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage devices.

The present disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the intended purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.

Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the method. The structure for a variety of these systems will appear as set forth in the description below. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the disclosure as described herein.

The present disclosure may be provided as a computer program product, or software, that may include a computer-readable medium having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to the present disclosure. A computer-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer system). For example, a computer-readable (e.g., computer-readable) medium includes a read only memory ("ROM"), random access memory ("RAM"), magnetic disk storage media, optical storage media, flash memory devices, etc..

Claim 1:
A method (<NUM>), comprising:
receiving, by a controller (<NUM>), a write command (<NUM>), said write command specifying a data item (410A...410N, 420A...<NUM>, 430A...<NUM>) and an identifier of a data stream (<NUM>, <NUM>, <NUM>) comprising the data item (410A... 410N, 420A...<NUM>, 430A...<NUM>), said identifier consisting of stream identification information enhanced by a data attribute;
determining, by parsing the identifier of the data stream (<NUM>, <NUM>, <NUM>), the data attribute shared by data items (410A...410N, 420A...<NUM>, 430A...<NUM>) comprised by the data stream (<NUM>, <NUM>, <NUM>), wherein the data attribute is encoded by a bit string of a pre-defined size starting from a pre-defined position within the identifier of the data stream (<NUM>, <NUM>, <NUM>), wherein the data attribute determines a respective distinct storage operation parameter; and
transmitting, to a non-volatile memory device (112A...112N), an instruction specifying the data item (410A...410N, 420A...<NUM>, 430A...<NUM>) and the storage operation parameter.