Storage media programming using adaptive write buffer release

Abstract

The present disclosure describes an apparatus and method for programming a storage medium with adaptive write buffer release. In some aspects, a media write manager of a storage medium system stores data received from a host interface in a write buffer. The media write manager determines parity information for the data stored in the write buffer, and then releases the write buffer after completing the determination of the parity information for the data. Then, after the write buffer is released, the media write manager can write at least a portion of the data to the storage medium. By releasing the write buffer of the storage medium system after determining the parity information, the write buffer can be released faster, which can result in improved write buffer utilization and increased write throughput of the storage medium system.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This disclosure claims priority to U.S. Provisional Patent Application No. 62 / 791,542, filed on January 11, 2019, and to U.S. Patent Application No. 16 / 737,137, filed on January 8, 2020, the entire contents of which are incorporated herein by reference. Background Art

[0003] Many computing and electronic devices include non-volatile memory for storing software, applications or device data. Additionally, most users utilize their devices (such as multimedia content or social media applications) to stream data or access services from various locations or on the move through data networks. As user demand for data and services continues to grow, storage providers have expanded the capacity and performance of storage drives to support data access associated with these activities of users and other data storage clients. Typically, the storage drive of a device includes a storage medium in which device data is written. For this reason, the device issues a write command to the storage drive, and the storage drive writes data to the storage medium as specified by each command. Therefore, the write performance of the storage drive usually depends on the rate at which the storage drive can complete the data write command of the device or storage client.

[0004] Storage drives typically include a write buffer for receiving data corresponding to a write command from a device. The storage drive then sends the data from the write buffer to a programming interface of the storage medium. However, the programming or writing speed of the storage medium is typically much slower than the speed of the write buffer. Additionally, most storage drives retain a copy of the data in the write buffer until the data is successfully programmed onto the storage medium, so as to recover the data when the storage medium programming fails and the data is lost. Thus, due to the slower programming speed of the storage medium, the write buffer of the storage drive may be retained or occupied for a long time. This prevents the write buffer from receiving subsequent data until the storage medium programming is completed, which reduces the write throughput of the storage drive, or requires an increased number of write buffers to maintain the write throughput. Summary of the invention

[0005] This summary is provided to introduce the subject matter, which will be further described in the detailed description and drawings. Therefore, this summary should not be regarded as describing essential features, nor should it be used to limit the scope of the claimed subject matter.

[0006] In some aspects, a media write manager of a storage medium system implements a method for storing data received from a host interface of a storage system including a storage medium in a write buffer. The method determines parity information for the data stored in the write buffer via a parity-based encoder. Alternatively or additionally, the data may be transferred to another internal buffer of the storage medium system. Then, in response to the determination of the parity information for the data being completed, the write buffer is released. The method also includes at least a portion of the data being written to the storage medium of the storage system after the write buffer is released from storing the data.

[0007] In other aspects, an apparatus includes: a host interface configured to communicate with a host system; a write buffer operably coupled to the host interface; a storage medium; and a media interface configured to allow access to the storage medium. The apparatus also includes a parity-based encoder and a media write manager configured to receive data from the host interface via one of the write buffers. The media write manager calculates parity information for the data received by the write buffer via the parity-based encoder and stores the parity information to the buffer of the parity-based encoder. In response to calculating the parity information for the data, the media write manager releases the write buffer, and after the write buffer is released from storing the data, at least a portion of the data is written to the storage medium of the apparatus.

[0008] In other aspects, a system on chip (SoC) is described that includes a host interface for communicating with a host system, a write buffer operably coupled to the host interface, a media interface for accessing a storage medium of a storage system, and a parity-based encoder. The SoC also includes a hardware-based processor and a memory storing processor-executable instructions, which instructions can implement a media write manager in response to execution of the hardware-based processor to store data received from the host interface to the write buffer. The media write manager also determines parity information for data stored in the write buffer via the parity-based encoder, and releases the write buffer in response to the determination of the parity information for the data. Then, after the write buffer is released from storing the data, the media write manager writes at least a portion of the data to the storage medium.

[0009] The details of one or more implementations are set forth in the accompanying drawings and the description below.Other features and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In the accompanying drawings and the following detailed description, details of one or more implementations of storage medium programming with adaptive write buffer release are set forth. In the drawings, the leftmost digit of a reference number identifies the drawing in which the reference number first appears. The same reference numbers are used in different instances in the description and drawings to indicate similar elements:

[0011] Figure 1 An example operating environment having a device in which a media write manager is implemented in accordance with one or more aspects of the present disclosure is shown.

[0012] Figure 2 An example configuration of a solid state drive is shown, in which Figure 1 A media write manager, write buffer, and redundant array of independent disks (RAID) encoder are implemented according to various aspects.

[0013] Figure 3 Example configurations of various hardware and firmware components are shown for implementing aspects of storage media programming with adaptive write buffer release.

[0014] FIG. 4A to FIG. 4E An example of storage medium programming with adaptive write buffer release in the context of die-level data redundancy is shown.

[0015] FIG. 5A to FIG. 5D An example of storage medium programming with adaptive write buffer release in the presence of plane-level data redundancy is shown.

[0016] Figure 6 Example methods of storage medium programming with adaptive write buffer release in accordance with one or more aspects are described.

[0017] Figure 7 An example method for freeing a write buffer based on calculation of parity information is depicted.

[0018] Figure 8 An example method for recovering from programming failures utilizing parity-based data reconstruction is depicted.

[0019] Fig. 9 An example system-on-chip (SoC) environment is shown in which various aspects of storage medium programming with adaptive write buffer release may be implemented.

[0020] Fig.10 An example storage system controller is shown in which a media write manager is implemented according to one or more aspects of the present disclosure. DETAILED DESCRIPTION

[0021] Conventional techniques for writing data to storage media typically hold the data in a write buffer until the data is programmed onto the storage media, which results in reduced write throughput of the storage drive or increased requirements for write buffers (e.g., the number or size of write buffers). Typically, storage drive firmware is used to manage the data path of the storage drive in an end-to-end manner, such as by converting data commands and managing data movement along the data path between a host interface and a storage medium interface. For example, the firmware may process a write command to receive corresponding data at the host interface, and send the data to the storage medium interface for programming to an appropriate area of ​​the storage medium.

[0022] Many storage drives operate in a "cache-on" mode, in which the firmware sends an acknowledgment to the host for a write command once the data for the write command is received by the storage drive's controller. Typically, cache-on mode is preferred because write command latency is shorter in cache-on mode and the host does not need to hold the data as quickly. In cache-on mode, the firmware typically holds the data in the controller's write buffer until an acknowledgment is received from the storage medium indicating that the program operation to transfer the data to the storage medium was successful. This is necessary because in the event of a program failure (e.g., a bad word line or a bad block), the firmware still has the data and may attempt to reprogram the data into the storage medium.

[0023] However, programming the storage medium takes a relatively long time (three milliseconds) compared to the typical transmission time of data through the write buffer (which is on the order of tens of microseconds). In other words, the length of time that the data received from the host occupies the write buffer is extended, primarily because of the contingency of programming failures, which are rare events. Additionally, the number of write buffers implemented by the controller is typically limited due to practical issues, such as layout area, data path architecture, power consumption, cost, etc. When the controller's limited write buffers are constantly occupied by data awaiting programming confirmation, the controller will be unable to receive additional data from the host until the write buffers become available. Thus, the limited number and inefficient utilization of write buffers imposes an upper limit on write throughput and can have a negative impact on the write performance of the storage drive.

[0024] The present disclosure describes an apparatus and technique for programming a storage medium with adaptive write buffer release. In contrast to conventional techniques for writing to storage media, the apparatus and technique described can implement a data write scheme for storage media that includes parity-based encoding (e.g., RAID) to enable data recovery in the event of a storage medium programming failure. By doing so, a media write manager of a storage controller can release a write buffer once parity information is calculated for data written to the storage medium. Alternatively or additionally, the data can be transferred to another internal buffer of the storage medium system before or while the parity information is calculated. In other words, the write buffer is released when the RAID calculation of the parity information (e.g., XOR information) is completed (e.g., tens of microseconds), rather than being held until a programming success confirmation is received from the storage medium (e.g., three milliseconds). Alternatively or additionally, the release of the write buffer can also be conditional on the data being copied from the write buffer to another internal buffer of the storage system or a storage medium interface for programming to the storage medium. Once released, in some cases, the write buffer can receive subsequent data from the host while the previously held data is being programmed to the storage medium. Thus, adaptive release of the write buffer can lead to more efficient write buffer utilization and / or enable the storage drive to be implemented with fewer or smaller write buffers. This reduction in write buffers or write buffer size can in turn reduce power consumption of the storage controller, facilitate improved integrated circuit layout, etc.

[0025] In various aspects of storage media programming utilizing adaptive write buffer release, a media write manager of a storage media system stores data received from a host interface to a write buffer. While the data is stored in the write buffer, the media write manager determines parity information for the data, and then releases the write buffer when the determination of the parity information for the data is complete. Then, after the write buffer is released, the media write manager may write at least a portion of the data to the storage media. By releasing the write buffer of the storage media system after determining the parity information, the write buffer may be freed more quickly, which may result in improved write buffer utilization and increased write throughput of the storage media system.

[0026] The following discussion describes an operating environment, technologies that may be employed in the operating environment, and a system on a chip (SoC) in which components of the operating environment may be embodied.In the context of the present disclosure, reference is made to an operating environment by way of example only.

[0027] Operating Environment

[0028] Figure 1An example operating environment 100 is shown with a host system 102 that can store or access various forms of data or information. Examples of host systems 102 may include laptop computers 104, desktop computers 106, and servers 108, any of which may be configured as a user device, a computing device, or as part of a storage network or cloud storage. Other examples (not shown) of host systems 102 may include tablet computers, set-top boxes, data storage devices, wearable smart devices, televisions, content streaming devices, high-definition multimedia interface (HDMI) media sticks, smart appliances, home automation controllers, smart thermostats, Internet of Things (IoT) devices, mobile Internet devices (MIDs), network attached storage (NAS) drives, aggregate storage systems, game consoles, automotive entertainment devices, automotive computing systems, automotive control modules (e.g., engine or powertrain control modules), etc. In general, host systems 102 may communicate or store data for any suitable purpose, such as to implement the functionality of a particular type of device, provide a user interface, enable network access, implement gaming applications, playback media, provide navigation, edit content, provide data storage, etc.

[0029] The host system 102 includes a processor 110 and a computer readable medium 112. The processor 110 may be implemented as a single-core or multi-core processor of any suitable type or number for executing instructions or commands of an operating system or other applications of the host system 102. The computer readable medium 112 (CRM 112) includes a memory (not shown) and a storage system 114 of the host system 102. The memory of the host system 102 may include any suitable type of volatile memory or non-volatile memory or a combination thereof. For example, the volatile memory of the host system 102 may include various types of random access memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), etc. The non-volatile memory may include a read-only memory (ROM), an electrically erasable programmable ROM (EEPROM), or a flash memory (e.g., NAND flash memory). These memories may store data associated with a user, an application, and / or an operating system of the host system 102 individually or in combination.

[0030] The storage system 114 of the host system 102 may be configured as any suitable type of data storage system, such as a storage device, a storage drive, a storage array, a storage volume, etc. Although described with reference to the host system 102, the storage system 114 may also be implemented separately as a standalone device or as part of a larger storage aggregate, such as a network attached storage device, an external storage drive, a data center, a server farm, or a virtual storage system (e.g., for cloud-based storage or services). Examples of the storage system 114 include a non-volatile memory express (NVMe) solid-state drive 116, a peripheral component interconnect express (PCIe) solid-state drive 118, a solid-state drive 120 (SSD 120), and a memory array 122, which may be implemented using any combination of storage devices or storage drives.

[0031] The storage system 114 includes a storage medium 124 and a storage medium controller 126 (storage controller 126) for managing various operations or functions of the storage system 114. The storage medium 124 may include or be formed from a non-volatile storage device on which data 128 or information of the host system 102 is stored. The storage medium 124 may be implemented using any type of solid-state storage medium such as flash memory, NAND flash memory, RAM, DRAM (e.g., for cache), SRAM, etc., or a combination thereof. In some cases, the data 128 stored in the storage medium 124 is organized into data (e.g., content) files or data objects, which are stored in the storage system 114 and accessed by the host system 102. The file type, size, or format of the data 128 may vary depending on the corresponding source, purpose, or application associated with the file. For example, the data 128 stored in the storage system 114 may include audio files, video files, text files, image files, multimedia files, spreadsheets, etc. Although described with reference to solid-state memory, aspects of storage media programming with adaptive write buffer release may also be implemented in magnetic-based or optical-based media types.

[0032] In general, the storage controller 126 manages the operation of the storage system 114 and enables the host system 102 to access the storage medium 124 for data storage. The storage controller 126 may be implemented by any suitable combination of hardware, firmware, or software to provide various functions of the storage system 114. The storage controller 126 may also manage or implement internal tasks or operations associated with the storage medium 124, such as data caching, data migration, garbage collection, thermal management (e.g., throttling), power management, etc. In this way, the storage controller 126 may receive host I / O from the host system 102 for data access, and queue (or generate) internal I / O associated with the internal operation of the storage medium 124.

[0033] In this example, the storage controller 126 also includes a storage media write manager 130 (media write manager 130), a write buffer 132, and a parity-based encoder, which is shown as a redundant array of independent disks (RAID) encoder 134. The write buffer 132 can receive or store data received from the host system 102 for writing to the storage medium 124. The RAID encoder 134 can calculate parity information (e.g., XOR bits) for data written to the storage medium 124 as part of a RAID stripe. The members or units of a RAID stripe can include any suitable partitions or regions of the storage medium, such as a die, plane, block, page, word line, etc. In general, the parity information provided by the RAID encoder can be used in conjunction with information from other RAID stripe members to recover data of a RAID stripe member when a programming operation of the member fails. RAID or parity-based data recovery can provide enhanced data reliability and protection from complete block or page failures of the storage medium.

[0034] In various aspects, the media write manager 130 can interact with the RAID encoder 134 to calculate parity information for the data stored in the write buffer 132. In some cases, the data can also be transferred to another internal buffer of the storage media system before or during the calculation of the parity information. If a programming operation to write data to the storage medium fails, the media write manager 130 can use the parity information to achieve data recovery instead of relying on the data maintained in the write buffer. Because the parity information enables data recovery, the media write manager can then release the write buffer in response to the calculation of the parity information (and / or the data is transferred to another internal buffer or storage medium), thereby freeing the write buffer 132 for reuse before or when the data is programmed into the storage medium. By doing so, the adaptive release of the write buffer can result in improved write buffer utilization and increased storage medium write throughput.

[0035] The host system 102 may also include an I / O port 136, a graphics processing unit 138 (GPU 138), and a data interface 140. In general, the I / O port 136 allows the host system 102 to interact with other devices, peripherals, or users. For example, the I / O port 136 may include or be coupled to a universal serial bus, a human interface device, audio input, audio output, etc. The GPU 138 processes and draws graphics-related data for the host system 102, such as user interface elements of an operating system, applications, etc. In some cases, the GPU 138 accesses a portion of local memory to draw graphics, or includes dedicated memory for drawing graphics (e.g., video RAM) for the host system 102.

[0036] The data interface 140 of the host system 102 provides a connection to one or more networks and other devices connected to those networks. The data interface 140 may include a wired interface (such as an Ethernet or fiber optic interface) for communicating over a local area network, an intranet, or the Internet. Alternatively or additionally, the data interface 140 may include a wireless interface that facilitates communication over a wireless network (such as a wireless local area network (LAN), a wide area wireless network (e.g., a cellular network), and / or a wireless personal area network (WPAN)). In accordance with one or more aspects of storage medium programming with adaptive write buffer release, any data transmitted through the I / O port 136 or the data interface 140 can be written to or read from the storage system 114 of the host system 102.

[0037] Figure 2 An example configuration of a solid state drive 202 is illustrated at 200, where a media write manager, write buffer, and RAID encoder may be implemented according to one or more aspects. In this example, a media write manager 130 and other components are shown in the context of a storage system 114 implemented as a solid state storage drive (SSD) 202. The SSD 202 may be coupled to any suitable host system 102 and implanted with a storage medium 124 including a plurality of NAND flash memory devices 204-0 to 204-n, where n is any suitable integer. In some cases, the NAND flash memory devices 204 include a plurality of flash channels of a storage device, die, or chip that are accessible or manageable at the channel level (device group) or device level (individual device). Although shown as a component of a storage controller 126, the media write manager 130 may be implemented separately from or external to the storage controller. In some cases, the media write manager 130 is implemented as part of a memory interface (such as a DRAM controller) or an interface associated with a storage controller.

[0038] Typically, the operation of the SSD 202 is enabled or managed by an instance of the storage controller 126, which in this example includes a host interface 206 for implementing communications with the host system 102 and a media interface 208 for implementing access to the storage medium 124. The host interface 206 can be configured to implement any suitable type of storage interface or protocol, such as Serial Advanced Technology Attachment (SATA), Universal Serial Bus (USB), PCIe, Advanced Host Controller Interface (AHCI), NVMe, NVM-OF, NVM Host Controller Interface Specification (NVMHCIS), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), Secure Digital I / O (SDIO), Fibre Channel, any combination thereof (e.g., M.2 or Next Generation Form Factor (NGFF) combination interface), etc. Alternatively or additionally, the media interface 208 can implement any suitable type of storage media interface, such as a flash memory interface, a flash bus channel interface, a NAND channel interface, a physical page addressing (PPA) interface, etc.

[0039] In various aspects, the SSD 202 or components of the storage controller 126 provide a data path between the host interface 206 to the host system 102 and the media interface 208 to the storage media 124. In this example, the storage controller 126 includes a processor core 210 for executing a kernel, firmware, or driver to implement the functions of the storage controller 126. In some cases, the processor core 210 may also execute processor-executable instructions to implement a media write manager 130 of the storage controller 126. Alternatively or additionally, the media write manager 130 may be executed from or run on hardware associated with the RAID encoder 134.

[0040] like Figure 2 As shown, the structure 212 of the storage controller 126 (which may include control and data buses) operably couples and supports communication between components of the storage controller 126. For example, the media write manager 130 may communicate with the write buffer 132, the RAID encoder 134, or the processor core 210 (e.g., firmware) to exchange data, information, or control signaling (e.g., buffer release interrupt) within the storage controller 126. The static random access memory 214 of the storage controller 126 may store processor executable instructions or code for the firmware or driver of the storage controller, which may be executed by the processor core 210. Alternatively or additionally, the write buffer 132 of the storage controller 126 may be implemented in the controller's SRAM 214.

[0041] In this example, the storage controller 126 includes a dynamic random access memory (DRAM) controller 216 and associated DRAM 218 for storing or caching various data as the storage controller 126 moves data between the host system 102, the storage medium 124, or other components of the storage controller. Figure 2 As shown in FIG. 1 , an instance of write buffer 132 is implemented in DRAM 218 and may be accessed or managed by DRAM controller 216. Storage controller 126 also includes an error correction code (ECC) encoder 220 that may be used to ECC encode data being programmed or written to storage medium 124 of SSD 202.

[0042] Figure 3 An example configuration of various hardware and firmware components is shown at 300 for implementing aspects of storage medium programming with adaptive write buffer release. In this example, components of the storage controller 126 are shown as abstract entities that can be implemented in firmware 302 and / or hardware 304 of the storage controller. This is just one example implementation of the various components, any of which can be implemented separately from or in combination with other components described herein. Alternatively or additionally, reference may be made to Figure 2 or Figure 3 Any of the described components may be implemented as an intellectual property block (IP block) or IP core, which is configured as a logical unit, unit and / or integrated circuit (IC) that provides the various described features of the component. For example, a component of storage controller 126 (e.g., media write manager 130) may be implemented as an IP core or IP block that includes a combination of hardware, firmware, or software to provide the corresponding functionality or implement the corresponding operation of the component.

[0043] In this example, the hardware 304 of the storage controller 126 includes a NAND flash memory device 204, a host interface 206, a media interface 208, a processor 210 (not shown), and an ECC encoder 220, which may be described with reference to FIG. Figure 2 306. The hardware 304 may also include a write buffer 132 and a RAID encoder 134, which are operably coupled to the RAID buffer 306. Shown separately in this example, the RAID buffer 306 may be implemented as part of the RAID encoder 134 and store parity information generated or calculated by the RAID encoder. The media write manager 130 may be implemented at least partially in the hardware 304 and interact with the write buffer 132 or the RAID encoder 134 to perform adaptive release of the write buffer 132, as described throughout this disclosure. Alternatively or additionally, the media write manager 130 may execute on the processor core 210 of the storage controller 126.

[0044] Typically, the firmware 302 of the storage controller 126 assists the hardware 304 in managing the data path between the host system 102 and the storage medium 124. In other words, the firmware 302 can convert commands or requests for data received from the host system 102 to enable access to the storage medium 124. Figure 3 As shown, the firmware 302 includes a host interface driver 308 for implementing a host command processor 310 on the host side and a media interface driver 312 for implementing a media command manager 314 on the storage medium side. Figure 3 As shown in FIG. 1 , a host input / output command 316 (host I / O 316) for data 318 (e.g., data corresponding to a write command) is received by the host command processor 310 and sent to an I / O scheduler of a flash translation layer 320 (FTL 320) of the storage controller 126. The FTL 320 and / or the I / O scheduler may process and schedule the host I / O 316, which may then be executed as a corresponding media input / output command 322 (media I / O 322) for storage media access through the media command manager 314.

[0045] The FTL 320 may manage command processing (eg, host I / O 316 translation and scheduling) to facilitate movement of host system data 318 within the storage system 114 and / or through the storage controller 126, such as to the storage media 124. Figure 3 As shown in , in the context of writing host data to storage media, the FTL 320 processes the host I / O 316 to manage or facilitate the movement of data 318 from the host interface 206 through the data path to the media interface 208, where the data 318 is programmed to the NAND flash memory device 204. To this end, the FTL 320 or firmware 302 can manage various components of the hardware 304 to facilitate the movement of data 318 from one component to the next. For example, the firmware 302 can cause the hardware 304 to obtain data 318 from the host interface 206 or move it from the host interface 206 to the write buffer 132, provide the data 318 (e.g., by passing or copying) to the RAID encoder 134, and / or provide the data 318 to the ECC encoder 220 for encoding. The firmware 302 can also cause the hardware 304 to send the data 318 or ECC-encoded data 324 to the media interface 208 for writing or programming to the NAND flash memory device 204.

[0046] In various aspects, the media write manager 130 can interact with the write buffer 132, the RAID encoder 134, the firmware 302, or other components of the hardware 304 to implement various aspects of storage media programming with adaptive write buffer release. In some cases, the media write manager 130 monitors the RAID encoder 134 for an indication of completion of calculation of parity information for data 318 (e.g., data for one host write command). Based on completion of the parity information calculation and a copy of the data being stored to another internal buffer (e.g., an ECC buffer), the write buffer 130 generates an interrupt to the firmware 302 to cause the release of the write buffer 132 storing the data 318 (e.g., data for one host write command). By doing so, the write buffer 132 is free and can be reused for the data 318 of the next write command of the host. This can also enable the storage drive to be implemented with fewer or smaller write buffers without affecting the write throughput of the storage drive.

[0047] FIG. 4A to FIG. 4E An example of storage medium programming with adaptive write buffer release in the context of die-level data redundancy is shown. Figure 4A Storing host data to storage media generally includes processing data 318 received at write buffer 132 and moving it to NAND flash memory 204 for programming into the NAND media, as shown in 400. Here, NAND flash memory 204 is illustrated as individual NAND die 1 204-1 through NAND die n 204n, where n is any suitable integer. FIG. 4A to FIG. 4E Any entity in the entity can be similar to the reference Figures 1 to 3 In this example, the storage controller 126 includes an instance of the RAID encoder 134 to implement RAID encoding, which can provide improved data reliability for the storage controller and enable recovery of data lost during NAND programming failures.

[0048] Typically, a RAID stripe may span storage blocks residing on different dies or planes of a storage medium. In high code rate applications (low overhead), a RAID stripe may also include blocks from the same die or plane of a storage medium. In this example, the RAID encoder 134 is implemented in a die RAID scheme (or die-level RAID), which can protect against failures of storage medium dies (e.g., NAND dies). In other aspects, a Reed-Solomon code encoder may be implemented in place of a RAID encoder to protect against failure events in multiple RAID stripe members (e.g., planes or dies).

[0049] like Figure 4AAs shown, the first write buffer 0 132-0 can receive the first data 318-0 from the host (such as the host system 102). The first data 318-0 is then provided to the RAID encoder 134 for calculating parity information for the first data 318-0, and is provided to the ECC encoder 220 for ECC encoding, and is programmed to the first plane (Plane 0 406-0) of the first NAND die 0 204-0. Typically, the data in the first write buffer 0 132-0 can be passed to the ECC encoder and / or storage medium and the RAID encoder for XOR generation in parallel. In this way, the first write buffer 0 132-0 is programmed to the storage medium, and the RAID buffer 306 accumulates XOR information until all RAID members have passed through the RAID encoder 134, and then the contents of the RAID buffer 306 can be written to the medium.

[0050] In this example, the RAID encoder 134 includes an XOR engine 402 to calculate XOR bits for the first data 318-0, which is stored to the first plane (Plane 0 404-0) of the RAID buffer 306. As noted, programming the first data 318-0 to the NAND flash memory may take more time (e.g., 3 to 4 milliseconds) than the calculation of the RAID encoder 134 parity information (e.g., 40 to 50 microseconds) or the transfer time to the storage medium.

[0051] continue Figure 4B In response to the calculation of the XOR bits by the RAID encoder 134, the media write manager 130 may release the first write buffer 0 132-0, as shown at 408. The first write buffer 0 132-0 may be released before or during the programming 410 of the first data 318-0 to the first NAND die 204-0. Thus, the first write buffer 0 132-0 may be released and available for reuse before the programming of the first data 318-0 to the NAND flash memory 204 is completed. In contrast to conventional storage media programming, the first write buffer 0 132-0 may receive additional data from the host before the first data 318-0 is completed being programmed, which may improve the write throughput of the storage controller 126 or the storage system 114.

[0052] like Figure 4BAs shown in FIG. 1 , when the second write buffer 1 132-1 receives the second data 318 1 from the host, the host data continues to be stored. Then, the second data 318 1 is provided to the RAID encoder 134 for calculating the parity information for the second data 318 1, and is provided to the ECC encoder 220 for ECC encoding, and is programmed to the second plane (Plane 1 406-1) of the first NAND die 0204-0. The XOR engine 402 calculates the XOR bits of the second data 318 1, which are stored in the second plane (Plane 1 404-1) of the RAID buffer 306.

[0053] continue Figure 4C , based on the completion of the calculation of the XOR bits of the second data 318-1 by the RAID encoder 134, the media write manager 130 may release the second write buffer 1 132-1, as shown at 412. Similar to the first write buffer 0 132-0, the second write buffer 1 132-1 may be released before or during the programming 414 of the second data 318-1 to the first NAND die 204-0. Therefore, before the programming of the second data 318 1 to the NAND flash memory 204 is completed, the second write buffer 112-12-1 may be released and available for reuse. In some cases, before the programming of the second data 318 1 to the NAND flash memory 204 is completed, the first write buffer 0 132-0 and the second write buffer 1 132-1 may be released for reuse.

[0054] Reference Figure 4C In the context of storage of host data, the third write buffer 2 132-2 receives the third data 318-2 from the host. The third data 318-2 is then provided to the RAID encoder 134 to calculate parity information for the third data 318-2, and is provided to the ECC encoder 220 for ECC encoding, and is programmed to the first plane (Plane 0 406-0) of the second NAND die 1204-1. The XOR engine 402 can calculate the XOR bits for the third data 318-2, which can be stored to the first plane (Plane 0 404-0) of the RAID buffer 306.

[0055] like Figure 4DAs shown in , in response to the RAID encoder 134 completing the calculation of the XOR bits of the third data 318-2, the media write manager 130 releases the third write buffer 2 132-2, as shown at 416. Before or during the programming 418 of the third data 318-2 to the second NAND die 204-1, the third write buffer 2 132-2 may be released. Therefore, before the programming of the third data 318-2 to the NAND flash memory 204 is completed, the third write buffer 2 132-2 may be released and available for reuse. In some cases, before the programming of the third data 318-2 to the NAND flash memory 204 is completed, the first write buffer 0 132-0, the second write buffer 1 132-1, and the third write buffer 2 132-2 may be released for reuse.

[0056] In this example, the storage of the host data is completed, and the fourth write buffer 3 132-3 receives the fourth data 3183 from the host. Then, the fourth data 3183 is provided to the RAID encoder 134 for calculating the parity information of the fourth data 3183, and is provided to the ECC encoder 220 for ECC encoding, and is programmed to the second plane (Plane 1 406-1) of the second NAND die 1 204-1. The XOR engine 402 calculates the XOR bits of the fourth data 318-3, which is stored in the second plane (Plane 1 404-1) of the RAID buffer 306. Similar to the other write buffers 132, when the calculation of the parity information of the fourth information 318-3 is completed, the media write manager can release the fourth write buffer 3 132-3.

[0057] refer to Figure 4E, the parity information or XOR bits calculated by the RAID encoder 134 can be stored or held in the RAID buffer 306 until the programming of the last NAND die 204 is completed. In the case of die-level RAID, the parity information of the RAID encoder 134 is programmed from the RAID buffer 306 into two planes 406 of the last NAND die n 204-n of the RAID stripe. By way of review, the host data 318 is striped across the other NAND die 204 members of the RAID stripe, such as NAND die 0 204-0 to NAND die n-1 (not shown). In this example, the ECC encoder 220 (two instances are shown for visual clarity) encodes the corresponding parity information (e.g., XOR bits) of the first plane 0 406-0 and the second plane 1 406-1. Then, the ECC-encoded parity information is programmed into the first plane 0 406-0 and the second plane 1 406-1 of the last NAND die n 204-n, respectively. By implementing RAID encoding, the data of either plane of a die that cannot be programmed (e.g., die k < n) can also be recovered as shown in Formulas 1 and 2.

[0058] (Die k, Plane 0) = (Die 0, Plane 0) XOR (Die 1, Plane 0) XOR … XOR (Die k-1, Plane 0) XOR (Die k+1, Plane 0) XOR … XOR (Die n, Plane 0)

[0059] Formula 1: Data recovery of Plane 0 of Die k

[0060] (Die k, Plane 1) = (Die 0, Plane 1) XOR (Die 1, Plane 1) XOR … XOR (Die k-1, Plane 1) XOR (Die k+1, Plane 1) XOR … XOR (Die n, Plane 1)

[0061] Formula 2: Data recovery of Plane 1 of Die k

[0062] In the case where the programming of the parity information into die n fails, the parity information can be held in the RAID buffer 306 until the programming of die n is completed, such that the parity data can be directly recovered from the RAID buffer 306.

[0063] Alternatively, once it is known that all (non-parity) members of the RAID stripe have been successfully programmed to the storage medium, the RAID buffer 306 may also be released early. In this case, the RAID buffer 306 may be released early, and if programming to the storage medium fails, the parity information may be rebuilt by reading all RAID members again. Alternatively, when parity reconstruction is not required, the stripe may lack RAID protection, and the stripe may be relocated to another location that effectively rebuilds the parity information.

[0064] FIG. 5A to FIG. 5D An example of storage medium programming with adaptive write buffer release in the context of plane-level data redundancy is shown. Figure 5A Storing host data to storage media generally includes processing data 318 received at write buffer 132 and moving it to NAND flash memory 204 for programming into the NAND media, as shown at 500. Here, NAND flash memory 204 is shown as individual NAND die 1 204-1 through NAND die n 204n, where n is any suitable integer. FIG. 5A to FIG. 5D Any entity in the entity can be similar to the reference Figure 1 4 to achieve. In this example, the storage controller 126 includes an instance of the RAID encoder 134 to implement RAID encoding, which can provide improved data reliability for the storage controller and enable recovery of data lost during NAND programming operations (e.g., block or page failures).

[0065] In this example, RAID encoder 134 is implemented in a plane RAID scheme (or plane-level RAID), which can protect against failures in the storage medium plane (e.g., NAND plane). In some cases, using plane RAID can reduce the number of die RAID (e.g., FIG. 4A to FIG. 4E ) In other aspects, a Reed-Solomon code encoder may be implemented in place of a RAID encoder to implement protection against failure events in multiple RAID stripe members (eg, planes or dies).

[0066] like Figure 5AAs shown in , the first write buffer 0 132-0 can receive the first data 318-0 from the host (such as the host system 102). The first data 318-0 is then provided to the RAID encoder 134 for calculating parity information for the first data 318-0, and is provided to the ECC encoder 220 for ECC encoding, and then programmed to the first plane (Plane 0 506-0) of the first NAND die 0 204-0. In this example, the RAID encoder 134 includes an XOR engine 502 to calculate the XOR bits for the first data 318-0, which are stored in the first plane (Plane 0 504-0) of the RAID buffer 306. As noted, programming the first data 318-0 can consume much more time than the calculation of the parity information of the RAID encoder 134 or the XOR engine 502.

[0067] continue Figure 5B , in response to the RAID encoder 134 calculating the XOR bits, the media write manager 130 may release the first write buffer 0 132-0, as shown at 508. The first write buffer 0 132-0 may be released before or during programming 510 of the first data 318-0 to the first NAND die 204-0. Thus, before programming of the first data 318-0 to the NAND flash memory 204 is complete, the first write buffer 0 132-0 may be released and available for reuse. In contrast to conventional storage media programming, the first write buffer 0 132-0 may receive additional data from the host before programming of the first data 318-0 is complete, which may improve write throughput of the storage controller 126 or storage system 114.

[0068] like Figure 5B As shown, when the second write buffer 1 132-1 receives the second data 318 1 from the host, the storage of the host data continues. Then, the second data 318 1 is provided to the RAID encoder 134 for calculating the parity information for the second data 318 1, and is provided to the ECC encoder 220 for ECC encoding, and then is programmed to the second plane (Plane 1 506-1) of the first NAND die 0 204-0. The XOR engine 502 calculates the XOR bits of the second data 318 1, which are stored in the second plane (Plane 1 504-1) of the RAID buffer 306.

[0069] continue Figure 5C, based on the completion of the calculation of the XOR bits for the second data 318-1 by the RAID encoder 134, the media write manager 130 may release the second write buffer 1 132-1, as shown at 512. Similar to the first write buffer 0 132-0, the second write buffer 1 132-1 may be released before or during the programming 514 of the second data 318-1 to the first NAND die 204-0. Therefore, before the programming of the second data 318-1 to the NAND flash memory 204 is completed, the second write buffer 1 132-1 may be released and available for reuse. Here, it is assumed that parity information has also been calculated for the third data (not shown), which has been sent to the programming interface of the NAND flash memory 204. In response to the calculation of the parity information for the third data, the media write manager 130 releases the third write buffer 2 132-2, as shown at 516. In this way, the release of the third write buffer 2 132 - 2 may occur before or during the programming 518 of the third data, thereby freeing the third write buffer 2 132 - 2 for reuse before the corresponding data is programmed into the NAND flash memory 204 .

[0070] like Figure 5C , the last write buffer 2n 132-2n (e.g., the last write buffer for the stripe) receives data 318-2n of the last plane member of the RAID stripe from the host. The data 318-2n is then provided to the RAID encoder 134 for calculation of parity information for the data 318-2n, and provided to the ECC encoder 220 for ECC encoding, and programmed to the first plane (Plane 0 506-0) of the nth NAND die n 204-n. The XOR engine 502 calculates the XOR bits for the data 318-2n, which is stored to the first plane (Plane 0 504-0) of the RAID buffer 306. Similar to the other write buffers 132, the media write manager can release the last write buffer 2n 132-2n when the calculation of the parity information of the information 318-2n is completed.

[0071] refer to Figure 5D, the parity information or XOR bits calculated by the RAID encoder 134 can be stored or held in the RAID buffer 306 until the programming of the last NAND die 204 is completed. In the case of planar RAID, the parity information for each plane (504-0 and 504-1) of the RAID encoder 134 is combined by XOR operation before being programmed into the second plane (plane 0 506-1) of the last NAND die n 204-n of the RAID stripe. By review, the host data 318 is striped across the other NAND plane members of the RAID stripe, such as the plane of NAND die 0 204-0 to the first plane of NAND die n. In this example, the ECC encoder 220 encodes the combined parity information (e.g., XOR bits) of the first plane 0 506-0 and the second plane 1 506-1. Then, the ECC-encoded parity information is programmed into the second plane 1 506-1 of the last NAND die n 204-n. By implementing RAID encoding, the data of any plane of a non-programmable die (e.g., die k < n) can also be recovered as shown in Formulas 3 and 4.

[0072] (Die k, plane 0) = (Die 0, plane 0) XOR (Die 1, plane 0) XOR … XOR (Die k-1, plane 0) XOR (Die k+1, plane 0) XOR … XOR (Die n, plane 0)

[0073] Formula 3: Data recovery of plane 0 of die k

[0074] (Die k, plane 1) = (Die 0, plane 1) XOR (Die 1, plane 1) XOR … XOR (Die k-1, plane 1) XOR (Die k+1, plane 1) XOR … XOR (Die n, plane 1)

[0075] Formula 4: Data recovery of plane 1 of die k

[0076] In the case where the programming of the parity information to die n fails, the parity information can be retained in the RAID buffer 306 until the programming of the second plane of die n is completed, such that the parity data is directly recoverable from the RAID buffer 306. These are just a few examples of programming the storage medium using the adaptive write buffer release, and other examples in the examples are implemented and described throughout this disclosure.

[0077] Techniques for adaptive write buffer release and data recovery

[0078] The following discussion describes techniques for storage media programming with adaptive write buffer release and / or parity-based data recovery. These techniques may be implemented using any of the environments and entities described herein, such as media write manager 130, write buffer 132, and / or RAID encoder 134. These techniques include Figures 6 to 8 Various methods are shown, each of which is shown as a set of operations that can be performed by one or more entities.

[0079] Methods 600 to 800 are not necessarily limited to the order of operations shown in the associated figures. Rather, any of the operations may be repeated, skipped, replaced, or reordered to implement the various aspects described herein. Furthermore, these methods may be used in conjunction with one another in whole or in part, regardless of whether they are performed by the same entity, separate entities, or any combination thereof. In the following discussion, for example, reference will be made to Figure 1 Operating environment 100 and Figures 2 to 5D Such references should not be construed as limiting the described aspects to the operating environment 100, entity, or configuration, but rather as an illustration of one example among various examples. Alternatively or additionally, the operations of the method may also be performed by reference to Fig. 9 System on Chip and / or Fig.10 The entity described by the storage system controller is implemented by or in conjunction with it.

[0080] Figure 6 An example method 600 for storage media programming with adaptive write buffer release is depicted, including operations performed by or in conjunction with a media write manager 130, a write buffer 132, or a RAID encoder 134 of a storage media controller.

[0081] At 602, data received from the host interface is stored in a write buffer. The write buffer may be implemented in an SRAM or DRAM of a storage controller. In some cases, the data received from the host interface corresponds to a write command of a host system from which the data is received via the host interface. The write command may specify a destination for the data in a storage medium such as a NAND flash memory of a storage system.

[0082] At 604, parity information is determined for the data stored in the write buffer using a parity-based encoder. Before or during the determination of the parity information, the data may be passed to an internal buffer or storage medium of the storage system. The parity-based encoder may include a RAID encoder with an XOR engine or an XOR buffer for determining parity information (e.g., XOR bits). The parity information may correspond to data of a plane or die of the storage medium to be written and other data of at least one other plane or at least one other die of the storage medium to be written. For example, the parity data may correspond to the XOR bits of data members of a RAID stripe across multiple die or planes of a NAND flash memory.

[0083] At 606, parity information for the data is stored in a buffer of the parity-based encoder. The parity information may be stored in a plane of the buffer based on a corresponding plane in the storage medium to which the data is programmed. Alternatively or additionally, parity information for the data and other data may be maintained in a buffer of the parity-based encoder until the parity information is successfully programmed into the storage medium.

[0084] At 608, in response to the determination of the parity information, the write buffer is released. Before the data is fully programmed into the storage medium, the write buffer is released. The encoder based on the parity check can provide a notification indicating the completion of the determination of the parity check information. In some cases, the encoder based on the parity check is monitored to detect when the determination or calculation of the parity check information is completed and / or stored in the buffer of the encoder based on the parity check. In response to the notification or detection of the completion of the determination of the parity check information, a notification or interruption can be sent to the firmware of the storage controller to cause the release of the write buffer. When released, the write buffer can be used for reuse, such as receiving subsequent data from the host interface.

[0085] At 610, after the write buffer is released from storing the data, at least a portion of the data is written to the storage medium. Because the write buffer is released after the parity information is determined, the write buffer can be released before the data is written or programmed to the storage medium. In this way, after the write buffer is released, data can continue to be written or programmed to the storage medium. In the event of a programming failure, the data can be recovered based on the parity information and without using the data previously held in the write buffer.

[0086] Optionally at 612, before completing the writing of the data to the storage medium, other data is stored to the write buffer. As noted, programming of data can continue after releasing the write buffer, which can be freely reused by firmware or other components of the storage controller. In some cases, additional data is stored to the write buffer while the previous data is being programmed to the storage medium. Various aspects of adaptive buffer release can improve write buffer utilization or increase write throughput of the storage medium by freeing and reusing the write buffer.

[0087] Figure 7 An example method 700 for freeing a write buffer based on calculation of parity information is depicted, including operations performed by or in conjunction with a media write manager 130, a write buffer 132, and / or a RAID encoder 134 of a storage media controller.

[0088] At 702, data from a host system is received at a write buffer. The data is received from the host system through a host interface of a storage controller. In some cases, the data is received or obtained from the host system as part of an I / O command to write the data to a storage medium associated with the storage controller.

[0089] At 704, the data is transferred from the write buffer to the RAID encoder. Typically, the data is transferred, passed, or sent to the RAID encoder while another internal buffer of the storage system maintains the data. In other words, the RAID encoder can process the data while another buffer holds a copy of the data or the data is sent to the storage medium for programming. By doing so, the host system can be freed from the data (e.g., cache-on mode), and the storage controller can have a local copy in the event of a data processing or programming failure.

[0090] At 706, parity information is calculated for data using a RAID encoder. The RAID encoder may include an XOR engine or XOR buffer for calculating or generating an XOR bit of data in a write buffer. The XOR bit (or parity information for data) may be maintained in a buffer of an encoder based on parity. In some cases, the RAID encoder is configured to generate an interrupt or provide a notification that the calculation of the parity information is complete. For example, the RAID encoder may provide an interrupt to the firmware of the storage controller, which interrupt indicates that the calculation of the parity information is complete and / or that the parity information for the data is maintained in the buffer of the RAID encoder.

[0091] At 708, in response to the completion of the calculation of the parity information for the data, the write buffer is released. Before releasing the write buffer, the data can be copied to another internal buffer of the storage system or programmed to the storage medium. Before the data is fully programmed into the storage medium, the write buffer can be released. In some cases, before starting the programming of the data to the storage medium, the write buffer is released. Alternatively or additionally, in response to an interrupt or notification provided by a RAID encoder, an ECC encoder, or other components of the storage controller, the write buffer can be released.

[0092] At 710, the data is encoded using an ECC encoder to provide ECC-encoded data. The ECC encoder may encode the data after or in parallel with the RAID encoding. In some cases, the ECC encoder receives the data from the RAID encoder after parity information is calculated based on the data.

[0093] At 712, after the write buffer is released from storing data, at least a portion of the ECC encoded data is written to the storage medium. Because the write buffer is released after the parity information is determined, the write buffer is released before or simultaneously with the data being ECC encoded by the ECC encoder. Thus, after the write buffer is released, writing or programming the ECC encoded data to the storage medium may occur or continue. In the event of a programming failure, the data may be recovered based on the parity information and without using the data previously held in the write buffer.

[0094] Optionally at 714, parity information is written to the storage medium. The parity information may be written to any suitable area of ​​the storage medium, such as the last die or plane of the RAID stripe. Typically, when the parity information is maintained by a RAID buffer, the parity information may be written to the last member of the RAID stripe. By doing so, in the event of a storage medium programming failure, the parity information may be recovered from the RAID buffer.

[0095] Optionally at 716, additional data is received at the write buffer. As noted, programming of ECC encoded data can continue after releasing the write buffer, which is free to be reused by firmware or other components of the storage controller. In some cases, additional data is received at the write buffer while previous data is being programmed to the storage medium. Aspects of adaptive buffer release can improve write buffer utilization or increase write throughput of the storage medium by releasing and reusing the write buffer.

[0096] Figure 8An example method 800 for recovering from programming failures utilizing parity-based data reconstruction is depicted, including operations performed by or in conjunction with a media write manager 130, a write buffer 132, and / or a RAID encoder 134 of a storage media controller.

[0097] Parity information is calculated using a RAID encoder for data received from a host interface at 802. The RAID encoder may include an XOR engine or XOR buffer for calculating or generating XOR bits for data in a write buffer.

[0098] At 804, the parity information is stored in a buffer of the RAID encoder. The XOR bits (or parity information for the data) may be maintained in a buffer of the parity-based encoder. In some cases, the RAID encoder is configured to generate an interrupt or provide a notification that the calculation of the parity information is complete.

[0099] At 806, the write buffer is released after calculating the parity information. The write buffer may be released before the data is fully programmed into the storage medium. Alternatively or additionally, the write buffer is released in response to an interrupt or notification provided by a RAID encoder, an ECC encoder, a media write manager, or other component of the storage controller.

[0100] At 808, programming of the data to the region of the storage medium is initiated. The data may be released to the storage medium interface for programming to the region (e.g., block, plane, or die) of the storage medium. In some cases, the data is sent to the flash memory controller via the flash memory interface of the storage controller for programming to the region of the flash memory. For example, the media I / O provided with the data may specify the plane to which the flash memory controller is to write the data to the storage medium.

[0101] At 810, a program failure is detected for programming of data to a storage medium. The program failure may include a page failure, a block failure, a plane failure, a die failure, etc. The program failure may be detected after the write buffer is released from storing data.

[0102] At 812, the data is reconstructed based on the parity information and corresponding data from other areas of the storage medium. By implementing RAID, the storage controller can reconstruct the lost data of the programming failure based on the parity information in the RAID buffer and data from other members (e.g., die or plane) of the RAID stripe. By doing so, the storage controller is able to reconstruct the data previously held by the released write buffer.

[0103] At 814, the reconstructed data is programmed to different areas of the storage medium. In the event of a programming failure, the storage controller is able to reconstruct the data lost due to the programming failure and attempt to reprogram the data to different areas of the storage medium, which can ensure the reliability of the data managed by the storage controller. Alternatively or additionally, if a programming failure occurs when attempting to write parity information to the last member of the RAID stripe, the parity information of the RAID buffer can also be reprogrammed to different areas of the storage medium. As noted, the parity information is maintained in the RAID buffer until programming to the storage medium is successfully completed to ensure the ability to recover from such a programming failure. Alternatively, the RAID buffer can also be released when the stripe is reallocated and its parity information is regenerated.

[0104] System on Chip

[0105] Fig. 9 An exemplary system on chip (SoC) 900 is shown that can implement various aspects of storage medium programming with adaptive write buffer release. SoC 900 can be implemented in any suitable system or device, such as a smartphone, a netbook, a tablet, an access point, a network attached storage device, a camera, a smart device, a printer, a set-top box, a server, a data center, a solid state drive (SSD), a hard disk drive (HDD), a storage drive array, a memory module, an automotive computing system, or any other suitable type of device (such as other devices described herein). Although described with reference to the SoC, Fig. 9 The entity may also be implemented as other types of integrated circuits or embedded systems, such as an application specific integrated circuit (ASIC), a memory controller, a storage controller, a communication controller, an application specific standard product (ASSP), a digital signal processor (DSP), a programmable SoC (PSoC), a system-in-package (SiP), or a field programmable gate array (FPGA).

[0106] The SoC 900 may be integrated with electronic circuits, microprocessors, memory, input-output (I / O) control logic, communication interfaces, firmware, and / or software for providing functionality of a computing device, a host system, or a storage system, such as any of the devices or components described herein (e.g., a storage drive or storage array). The SoC 900 may also include an integrated data bus or interconnect structure (not shown) that couples various components of the SoC for controlling signaling, data communications, and / or routing between components. The integrated data bus, interconnect structure, or other components of the SoC 900 may be exposed or accessed through an external port, a parallel data interface, a serial data interface, a structure-based interface, a peripheral component interface, or any other suitable data interface. For example, a component of the SoC 900 may access or control an external storage medium through an external interface or an off-chip data interface.

[0107] In this example, the SoC 900 includes various components, such as input-output (I / O) control logic 902 and a hardware-based processor 904 (processor 904), such as a microprocessor, a processor core, an application processor, a DSP, etc. The SoC 900 also includes any type of memory 906, which may include RAM, SRAM, DRAM, non-volatile memory, ROM, one-time programmable (OTP) memory, multiple-time programmable (MTP) memory, flash memory and / or other suitable electronic data storage devices and / or combinations thereof. In some aspects, the processor 904 and the code stored on the memory 906 are implemented as a storage system controller or a storage aggregator to provide various functions associated with programming of storage media with adaptive write buffer release. In the context of the present disclosure, the memory 906 stores data, code, instructions or other information via non-transient signals and does not include carriers or transient signals. Alternatively or additionally, the SoC 900 may include a data interface (not shown) for accessing additional or expandable off-chip storage media, such as solid-state memory (e.g., flash memory or NAND memory), magnetic-based storage media, or optical-based storage media.

[0108] The SoC 900 may also include firmware 908, applications, programs, software and / or operating systems, which may be embodied as processor executable instructions maintained on the memory 906 for execution by the processor 904 to implement the functions of the SoC 900. The SoC 900 may also include other communication interfaces, such as a transceiver interface for controlling or communicating with components of a local on-chip (not shown) or off-chip communication transceiver. Alternatively or additionally, the transceiver interface may also include or implement a signal interface to transmit radio frequency (RF), intermediate frequency (IF) or baseband frequency signals off-chip to facilitate wired or wireless communication through a transceiver, a physical layer transceiver (PHY), or a media access controller (MAC) coupled to the SoC 900. For example, the SoC 900 may include a transceiver interface configured to allow storage via a wired or wireless network, such as to provide a network attached storage (NAS) volume capable of implementing storage medium programming with adaptive write buffer release.

[0109] The SoC 900 also includes a media write manager 130, a write buffer 132, and a RAID encoder 134, which can be implemented separately as shown, or can be combined with storage components, data interfaces, or can be accessible through an off-chip interface. In accordance with various aspects of storage media programming with adaptive write buffer release, the media write manager 130 can interact with the RAID encoder 134 to calculate parity information for data stored in the write buffer 132. Then, in response to the calculation of the parity information, the media write manager can release the write buffer, thereby releasing the write buffer 132 for reuse before or while the data is programmed to the storage medium. By doing so, the adaptive release of the write buffer can result in improved write buffer utilization and increased storage media write throughput. As described with reference to the various aspects presented herein, any of these entities may be embodied as different or combined components. Reference Figure 1 corresponding components or entities of the environment 100, Figures 2 to 5D The corresponding configuration shown in and / or Figures 6 to 8 The methods shown in describe examples of these components and / or entities or corresponding functions. All or part of the media write manager 130 may be implemented as processor-executable instructions maintained by the memory 906 and executed by the processor 904 to implement various aspects and / or features of storage media programming with adaptive write buffer release.

[0110] The media write manager 130 may be implemented independently or in combination with any suitable components or circuit systems to implement the various aspects described herein. For example, the media write manager 130 may be implemented as part of a DSP, a processor / memory bridge, an I / O bridge, a graphics processing unit, a memory controller, a storage controller, an arithmetic logic unit (ALU), etc. The media write manager 130 may also be provided internally with other entities of the SoC 900, such as being integrated with the processor 904, the memory 906, the storage medium interface, or the firmware 908 of the SoC 900. Alternatively or additionally, the media write manager 130, the RAID encoder 134, the RAID encoder 134, and / or other components of the SoC 900 may be implemented as hardware, firmware, fixed logic circuitry, or any combination thereof.

[0111] As another example, consider Fig.10 , which illustrates an example storage system controller 1000 according to one or more aspects of storage medium programming with adaptive write buffer release. In various aspects, the storage system controller 1000 or any combination of its components can be implemented as a storage drive controller, storage media controller, NAS controller, fabric interface, NVMe target, or storage aggregation controller for solid-state storage media or other types of storage media. In some cases, similar to or referenced to Fig. 9 Of the components of the described SoC 900, storage system controller 1000 is implemented. In other words, an instance of SoC 900 may be configured as a storage system controller, such as storage system controller 1000, for managing solid-state (eg, NAND flash-based) media.

[0112] In this example, the storage system controller 1000 includes input / output (I / O) control logic 1002 and a processor 1004, such as a microprocessor, a processor core, an application processor, a DSP, etc. In some aspects, the processor 1004 and firmware of the storage system controller 1000 can be implemented to provide various functions associated with storage medium programming with adaptive write buffer release, such as those described in any of the methods 600 to 800 with reference to the methods. The storage system controller 1000 also includes a host interface 1006 (e.g., a SATA, PCIe, NVMe, or fabric interface) and a storage medium interface 1008 (e.g., a NAND interface), which respectively implement access to a host system and a storage medium. The storage system controller 1000 also includes a flash translation layer 1010 (FTL 1010), a device level manager 1012, and an I / O scheduler (not shown). In some aspects of storage media programming with adaptive write buffer release, the FTL 1010 processes write commands received via the host interface 1006 to manage data movement within or through the storage system controller 1000 .

[0113] The storage system controller 1000 also includes instances of a media write manager 130, a write buffer 132, a RAID encoder 134, and an ECC encoder 220. Any or all of these components may be implemented separately as shown, or may be combined with the processor 1004, the host interface 1006, the storage medium interface 1008, the flash translation layer 1010, the device level manager 1012, and / or the I / O scheduler. Figure 1 A corresponding component or entity of the environment 100 or Figures 2 to 5D Examples of these components and / or entities or corresponding functions are described with reference to the corresponding configurations shown. According to various aspects of storage medium programming with adaptive write buffer release, the media write manager 130 can interact with the RAID encoder 134 to calculate parity information for data stored in the write buffer 132. The media write manager can then release the write buffer in response to the calculation of the parity information, thereby freeing the write buffer 132 for reuse before or while the data is programmed to the storage medium. By doing so, the adaptive release of the write buffer can result in improved write buffer utilization and increased storage medium write throughput. The media write manager 130 can be implemented in whole or in part as processor-executable instructions maintained by a memory of the controller and executed by the processor 1004 to implement various aspects and / or features of storage medium programming with adaptive write buffer release.

[0114] Although the subject matter has been described in language specific to structural features and / or methodological operations, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific examples, features, or operations described herein, including the order in which they are performed.

Claims

1. A method for storage medium programming with adaptive write buffer release, comprising: storing first data in a write buffer, the first data being received from a host interface of a storage system, the storage system comprising a storage medium; determining, using a parity-based encoder, parity information for the first data stored in the write buffer; In response to completion of the determination of the parity information for the first data, releasing the write buffer; after the write buffer is released from storing the first data, writing at least a portion of the first data to the storage medium of the storage system; as well as Before completing the writing of the first data to the storage medium of the storage system, second data is stored in the write buffer. 2 . The method of claim 1 , further comprising storing the parity information for the first data in a buffer associated with the parity-based encoder while the first data is being written to the storage medium.

3. The method according to claim 2, further comprising: writing the parity information for the first data from the buffer associated with the parity-based encoder to the storage medium of the storage system; or Upon completion of the writing of the first data to the storage medium of the storage system, the parity information for the first data is deleted from the buffer associated with the parity-based encoder.

4. The method according to claim 1, further comprising: encoding the first data via an error correction code (ECC) encoder to provide ECC-encoded data; as well as The ECC-encoded data is written to the storage medium of the storage system.

5. The method of claim 4, wherein the first data is transmitted from the parity-based encoder to the ECC encoder, and the method further comprises: monitoring said parity-based encoder to detect said completion of said determining of said parity information for said first data; as well as After the transmission of the first data to the ECC encoder, in response to the completion of the determination of the parity information for the first data, firmware of the storage system is notified to release the write buffer.

6. The method of claim 1, wherein the parity-based encoder is a Redundant Array of Independent Disks (RAID) encoder of the storage system, and the parity information comprises XOR parity bits calculated by the RAID encoder for the first data.

7. The method according to claim 1, wherein: The storage medium is a flash memory; The first data is written to a plane of the flash memory or a die of the flash memory; The second data is written to another plane of the flash memory or another die of the flash memory; and The parity information corresponds to the first data written to the plane or the die of the flash memory and the second data written to the other plane or the other die of the flash memory.

8. The method of claim 1 , wherein the first data is written to a region of the storage medium as part of a storage medium programming operation, and the method further comprises: detecting a failure of the programming operation to write the first data to the area of ​​the storage medium; reconstructing the first data based on the parity information and corresponding data from other areas of the storage medium; as well as The reconstructed first data is written to a different area of ​​the storage medium.

9. An apparatus for programming a storage medium using adaptive write buffer release, comprising: a host interface configured to communicate with a host system; a write buffer operably coupled to the host interface; Storage media; a medium interface configured to enable access to the storage medium; Parity-based encoders; as well as A media write manager, the media write manager being configured to: receiving first data from the host interface via one of the write buffers; calculating, via the parity-based encoder, parity information for the first data received by the write buffer; storing the parity information for the first data in a buffer of the parity-based encoder; releasing the write buffer in response to calculating the parity information for the first data, the write buffer being released before the first data is written to the storage medium of the device; writing at least a portion of the first data to the storage medium of the device after the write buffer is released from storing the first data; as well as Before completing writing of the first data to the storage medium of the device, second data is received from the host interface via the released write buffer.

10. The apparatus of claim 9, wherein the media write manager is further configured to: writing the parity information for the first data from the buffer of the parity-based encoder to the storage medium of the device or another memory of the device; or Upon completion of the writing of the first data to the storage medium of the device, the parity information for the first data is flushed from the buffer of the parity-based encoder.

11. The apparatus of claim 9, further comprising an error correction code (ECC) encoder and wherein the media write manager is further configured to: encoding the first data via the ECC encoder to provide ECC-encoded data; and The ECC encoded data is written to the storage medium of the device.

12. The apparatus of claim 11, wherein the first data is sent from the parity-based encoder to the ECC encoder, and the media write manager is further configured to: receiving a notification from the parity-based encoder indicating completion of the calculation of the parity information for the first data; and After the first data is sent to the ECC encoder, in response to the completion of the calculation of the parity information for the first data, an interrupt is generated to the firmware of the device to cause the release of the write buffer.

13. The apparatus of claim 9, wherein the first data is written to a region of the storage medium as part of a storage medium programming operation, and the media write manager is further configured to: detecting a failure of the programming operation to write the first data to the area of ​​the storage medium; reconstructing the first data based on the parity information and corresponding data from other areas of the storage medium; as well as The reconstructed first data is written to a different area of ​​the storage medium.

14. The device according to claim 9, wherein: The storage medium is a flash memory; The first data is written to a plane of the flash memory or a die of the flash memory; The second data is written to another plane of the flash memory or another die of the flash memory; and The parity information corresponds to the first data written to the plane or the die of the flash memory and the second data written to the other plane or the other die of the flash memory.

15. A system on chip (SoC) for storage medium programming with adaptive write buffer release, comprising: a host interface, the host interface communicating with a host system; a write buffer operably coupled to the host interface; A media interface, wherein the media interface is used to access a storage system storage medium; Parity-based encoders; Hardware-based processors; a memory storing processor-executable instructions that, in response to execution by the hardware-based processor, implement a media write manager to: storing first data received from the host interface into one of the write buffers; determining, via the parity-based encoder, parity information for the first data stored to the write buffer; releasing the write buffer in response to the determining of the parity information for the first data; After the write buffer is released from storing the first data, writing at least a portion of the first data to the storage medium; as well as Before completing the writing of the first data to the storage medium of the storage system, second data is stored in the released write buffer.

16. The SoC of claim 15, wherein the media write manager is further implemented as: storing the parity information for the first data in a buffer associated with the parity-based encoder when the first data is written to the storage medium; or The parity information for the first data is written from the buffer associated with the parity-based encoder to the storage medium of the storage system.

17. The SoC of claim 15, wherein the media write manager is further implemented as: receiving a notification from the parity-based encoder indicating completion of the determination of the parity information for the first data; and An interrupt is generated to firmware of the SoC to cause the release of the write buffer.

18. The SoC of claim 15, wherein the first data is written to a region of the storage medium as part of a storage medium programming operation, and the media write manager is further configured to: detecting a failure of the programming operation to write the first data to the area of ​​the storage medium; reconstructing the first data based on the parity information and corresponding data from other areas of the storage medium; as well as The reconstructed first data is written to a different area of ​​the storage medium.

19. The SoC of claim 15, further comprising an error correction code (ECC) encoder and wherein the media write manager is further configured to: encoding the first data via the ECC encoder to provide ECC-encoded data; and The ECC-encoded data is written to the storage medium of the storage system.

20. The SoC of claim 15, wherein the parity-based encoder is a Redundant Array of Independent Disks (RAID) encoder of the SoC, and the parity information comprises XOR parity bits calculated by the RAID encoder for the first data.

Images