Method of controlling operation of a raid system

Abstract

Embodiments herein provide a method for controlling operations of a redundant array of independent disks (RAID) data storage system, the system comprising a host device and a plurality of solid state drives (SSDs). The method comprises performing, by at least one SSD, recovery of missing data by performing an automatic rebuild operation. The method further comprises performing, by the at least one SSD, an automatic correction operation based on an IO error. The method further comprises creating, by all of the plurality of SSDs in the RAID data storage system, a snapshot of an address mapping table. The automatic rebuild operation, the automatic correction operation, and the creation of the snapshot of the address mapping table are all performed without intervention of the host device.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to Indian Patent Application 201941016055, filed on April 23, 2019, with the Intellectual Property Office of India, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The example embodiments described herein relate to computer networks. For example, at least some example embodiments relate to methods for controlling the operation of a RAID system, including a host device and / or multiple SSDs. Background Technology

[0004] Typically, distributed storage systems can be used in a large number of systems interconnected by one or more networks. A failure in part of a distributed storage system, or even the entire distributed storage system, can affect the operation of many systems coupled to it. Therefore, it may be desirable for distributed storage systems to have high processing speed and performance while maintaining high reliability.

[0005] Distributed storage systems typically include various mechanisms, such as error detection and correction, to prevent data loss. Furthermore, distributed storage systems include distribution algorithms to distribute data across multiple storage devices (e.g., SSDs). Each storage device can include error detection and correction algorithms, such as RAID type algorithms (e.g., RAID 5 and RAID 6) or Reed-Solomon code.

[0006] The above information is provided for background information purposes only and to assist the reader. The applicant has not made any decision, nor has it asserted whether any of the above applies to the prior art of this application. Summary of the Invention

[0007] At least some example embodiments provide methods for controlling the operation of a RAID system, which includes a host device and multiple SSDs.

[0008] At least some example implementations offload the functionality of the host device by shifting specific functions of the host device to multiple SSDs.

[0009] At least some example embodiments detect IO errors corresponding to the failure of at least one of the multiple SSDs via a host device and initiate an automatic rebuild operation in at least one of the multiple SSDs.

[0010] At least some example embodiments detect IO errors by the host device that do not correspond to a failure of at least one of the multiple SSDs, and initiate automatic error correction operations in at least one of the multiple SSDs.

[0011] At least some example implementations use at least one SSD to perform an automatic rebuild operation to recover lost data without intervention from the host device.

[0012] At least some example embodiments involve a host device enabling a snapshot feature for at least one SSD from multiple SSDs to manage snapshots of the address mapping table.

[0013] At least some example implementations create snapshots of the address mapping table for all SSDs in a RAID data storage system.

[0014] At least some example implementations involve at least one SSD performing automatic error correction based on IO errors.

[0015] Therefore, at least some of the example embodiments described herein provide methods for controlling the operation of a Redundant Array of Independent Disks (RAID) data storage system, which includes a host device and multiple solid-state drives (SSDs).

[0016] In some example embodiments, the method includes: detecting an I / O error by a host device; determining by the host device whether the I / O error corresponds to a failure of at least one of the plurality of SSDs; configuring an address mapping table by the host device such that the address mapping table includes striped data of a spare SSD; in response to the I / O error corresponding to the failure of the at least one SSD, sending an automatic rebuild command to the plurality of SSDs, the automatic rebuild command instructing the plurality of SSDs to perform an automatic rebuild operation such that the automatic rebuild command includes information about the spare SSD; and receiving an I / O error correction completion command from each of the plurality of SSDs.

[0017] In some other example embodiments, the method includes: receiving an autocorrect request from a host device by at least one SSD from a plurality of SSDs, the autocorrect request requesting to perform an autocorrect operation, the autocorrect request including information about IO errors; recovering data from other SSDs among the plurality of SSDs by at least one SSD based on the IO errors through the execution of the autocorrect operation; and sending an autocorrect completion command to the host device by at least one SSD after the execution of the autocorrect operation.

[0018] In some other example embodiments, the method includes: in response to an I / O error corresponding to a failure of at least one SSD, at least one of a plurality of SSDs receiving an automatic rebuild command from a host device, the automatic rebuild command requesting the execution of an automatic rebuild operation, the automatic rebuild command including information about a spare SSD of the plurality of SSDs; the at least one SSD reading striped data from an address mapping table of the spare SSD; the at least one SSD recovering lost data by performing the automatic rebuild operation without intervention from the host device; and after performing the automatic rebuild operation, the at least one SSD sending an automatic rebuild complete command to the host device.

[0019] In some other example embodiments, the method includes: in response to an I / O error corresponding to a failure of at least one SSD, at least one of a plurality of SSDs receiving an automatic rebuild command from a host device, the automatic rebuild command requesting the execution of an automatic rebuild operation, the automatic rebuild command including information about a spare SSD of the plurality of SSDs; the at least one SSD reading striped data from an address mapping table of the spare SSD; the at least one SSD recovering lost data by performing the automatic rebuild operation without intervention from the host device; and after performing the automatic rebuild operation, the at least one SSD sending an automatic rebuild complete command to the host device.

[0020] In some other example embodiments, the method includes: a host device enabling snapshot features for at least one of a plurality of SSDs to manage snapshot data of an address mapping table; the host device sending a snapshot version and a timestamp to the at least one SSD to retrieve snapshot data of the address mapping table; and the host device receiving the snapshot data from the at least one SSD based on the snapshot version and the timestamp.

[0021] In some other example embodiments, the method includes: detecting a match between a snapshot version and a timestamp by at least one of a plurality of SSDs; and, in response to detecting a match, triggering the plurality of SSDs to create a snapshot of an address mapping table by the at least one SSD.

[0022] Therefore, at least some example embodiments herein provide a host device coupled to multiple solid-state drives (SSDs) in a redundant array of independent disks (RAID) data storage system. The host device includes memory, a processor, and an automatic rebuild engine. The automatic rebuild engine is configured to detect failure of at least one of the multiple SSDs and configure an address mapping table including striped data at a spare SSD. Furthermore, the automatic rebuild engine is also configured to instruct an automatic rebuild command to each of the multiple SSDs to perform an automatic rebuild operation, wherein the automatic rebuild command includes information about the spare SSD and receives an automatic rebuild completion command from each SSD.

[0023] Therefore, the example embodiments herein provide a host device coupled to multiple solid-state drives (SSDs) in a redundant array of independent disks (RAID) data storage system. The host device includes memory, a processor, and a snapshot engine. The snapshot engine is configured to enable snapshot functionality for at least one SSD from the multiple SSDs to manage snapshots of an address mapping table, and to send snapshot versions and timestamps to at least one SSD to retrieve snapshot data from the address mapping table. The snapshot engine is also configured to receive snapshot data from at least one SSD based on the snapshot version and timestamp.

[0024] Therefore, the example embodiments herein provide a host device coupled to multiple solid-state drives (SSDs) in a redundant array of independent disks (RAID) data storage system. The host device includes memory, a processor, and an auto-correction engine. The auto-correction engine is configured to detect I / O errors and configure an auto-correction request including metadata information about the I / O errors. Furthermore, the auto-correction engine is also configured to send auto-correction requests to each of the multiple SSDs to perform auto-correction operations and to receive an auto-correction completion command from each SSD.

[0025] Therefore, the example embodiments herein provide an SSD coupled to a host device in a Redundant Array of Independent Disks (RAID) data storage system comprising multiple solid-state drives (SSDs). The SSD includes memory, a processor, and an automatic rebuild engine. The automatic rebuild engine is configured to receive an automatic rebuild command from the host device for performing an automatic rebuild operation, wherein the automatic rebuild command includes information about a spare SSD and reads striped data stored in an address mapping table of the spare SSD. Furthermore, an automatic error correction engine is also configured to recover lost data by performing the automatic rebuild operation without intervention from the host device and to send an automatic rebuild completion command to the host device.

[0026] Therefore, the example embodiments herein provide an SSD coupled to a host device in a redundant array of solid-state drives (SSDs) data storage system. The SSD includes memory, a processor, and a snapshot engine. The snapshot engine is configured to determine a match between a snapshot version and a timestamp, and in response to detecting a match, triggers a snapshot that creates an address mapping table.

[0027] Therefore, the example embodiments herein provide an SSD coupled to a host device in a Redundant Array of Independent Disks (RAID) data storage system comprising multiple solid-state drives (SSDs). The SSD includes memory, a processor, and an auto-error correction engine. The auto-error correction engine is configured to receive an auto-error correction request from the host device for performing auto-error correction operations, wherein the auto-error correction request includes information about I / O errors. Furthermore, the auto-error correction engine is also configured to recover data by performing auto-error correction operations based on I / O operations and to send an auto-error correction completion command to the host device.

[0028] These and other aspects of the exemplary embodiments herein will be better understood and appreciated when considered in conjunction with the following description and accompanying drawings. However, it should be understood that while the following description indicates some exemplary embodiments and their many specific details, it is given by way of illustration rather than limitation. Many changes and modifications may be made within the scope of the exemplary embodiments herein without departing from the spirit of the invention, and the exemplary embodiments herein encompass all such modifications. Attached Figure Description

[0029] Example embodiments are illustrated in the accompanying drawings, wherein the same reference numerals denote corresponding parts in the various figures. The example embodiments herein will be better understood from the following description with reference to the accompanying drawings, wherein:

[0030] Figure 1 This is an example illustrating a traditional NVM express over Fabrics (NVMf) all-flash array;

[0031] Figure 2 This is a block diagram of a host device coupled to multiple solid-state drives (SSDs) in a redundant array of independent disks (RAID) data storage system according to an example embodiment disclosed herein;

[0032] Figure 3 This is a block diagram of an SSD coupled to a host device in a redundant array of solid-state drives (SSDs) data storage system comprising multiple solid-state drives (SSDs) according to an example embodiment disclosed herein;

[0033] Figure 4 This is a flowchart illustrating a method for initiating an automatic rebuild operation by a host device according to an example embodiment disclosed herein;

[0034] Figure 5 This is a flowchart illustrating a method for recovering lost data without intervention from a host device by performing an automatic reconstruction operation, according to an example embodiment disclosed herein;

[0035] Figure 6 This is a flowchart illustrating a method for receiving snapshot data from at least one SSD according to an example embodiment disclosed herein;

[0036] Figure 7 This is a flowchart illustrating a method for triggering the creation of an address mapping table by at least one SSD, according to an example embodiment disclosed herein;

[0037] Figure 8 This is a flowchart illustrating a method for initiating automatic error correction operations by a host device according to an example embodiment disclosed herein;

[0038] Figure 9 This is a flowchart illustrating a method for recovering data by performing automatic error correction operations by at least one SSD, according to an example embodiment disclosed herein;

[0039] Figure 10 This is an example illustrating an automatic rebuild operation in a Just Bunch of Flash (JBOF) disk group according to an example embodiment disclosed herein. Detailed Implementation

[0040] Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. In the following description, only specific details such as detailed configurations and components are provided to aid in a comprehensive understanding of these embodiments of the present disclosure. Therefore, it will be apparent to those skilled in the art that various changes and modifications can be made to the exemplary embodiments described herein without departing from the scope and spirit of the present disclosure. Furthermore, for clarity and brevity, descriptions of well-known functions and structures have been omitted.

[0041] Furthermore, the various exemplary embodiments described herein are not necessarily mutually exclusive, as some exemplary embodiments may be combined with one or more other exemplary embodiments to form new embodiments.

[0042] In this document, unless otherwise stated, the term "or" as used herein means non-exclusive. The examples used herein are intended only to facilitate understanding of how the exemplary embodiments described herein can be practiced, and further to enable those skilled in the art to practice the exemplary embodiments described herein. Therefore, the examples should not be construed as limiting the scope of the exemplary embodiments described herein.

[0043] As is conventional in the art, exemplary embodiments can be described and illustrated based on blocks that perform one or more described functions. These blocks, referred to herein as units, engines, managers, modules, etc., are physically implemented by analog and / or digital circuitry, such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuitry, etc., and may optionally be driven by firmware and / or software. For example, the circuitry may be embodied in one or more semiconductor chips or on a substrate support such as a printed circuit board. The circuitry constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware performing some functions of the block and a processor performing other functions of the block. Without departing from the scope of this disclosure, each block of the exemplary embodiments may be physically divided into two or more interactive and discrete blocks. Similarly, without departing from the scope of this disclosure, the blocks of the exemplary embodiments may be physically combined into more complex blocks.

[0044] Therefore, the example embodiments herein provide a method for controlling the operation of a Redundant Array of Independent Disks (RAID) data storage system, including a host device and multiple solid-state drives (SSDs). The method includes performing lost data recovery by at least one SSD through an automatic rebuild operation. The method also includes performing an automatic error correction operation based on I / O errors by at least one SSD. Furthermore, the method includes creating a snapshot of the address mapping table by all SSDs in the RAID data storage system. The automatic rebuild operation, the automatic error correction operation, and the creation of the address mapping table snapshot are all performed without intervention from the host device.

[0045] In an example embodiment, the method includes detecting I / O errors by a host device, and detecting whether the I / O error corresponds to a failure of at least one of a plurality of SSDs. Furthermore, the method includes performing either automatic error correction or automatic rebuild operations based on the result of detecting whether the I / O error corresponds to a failure of at least one SSD.

[0046] For example, when an IO error does not correspond to a failure of at least one of the plurality of SSDs, the method may include an automatic error correction request configured by a host device, including metadata information about the IO error; and the host device sending an automatic error correction command to each of the plurality of SSDs to perform an automatic error correction operation.

[0047] Furthermore, when an IO error corresponds to the failure of at least one of a plurality of SSDs, the method may include: configuring an address mapping table by a host device that includes striped data at a spare SSD; the host device instructing an automatic rebuild command to each of the plurality of SSDs to perform an automatic rebuild operation, wherein the automatic rebuild command includes information about the spare SSD.

[0048] In addition, the method includes receiving an IO error correction completion command from each SSD by the host device after the SSD performs an automatic error correction or automatic rebuild operation.

[0049] In the example embodiment, multiple SSDs belong to a single RAID group.

[0050] In the example embodiment, an address mapping table including striped data is configured in the controller memory buffer (CMB) of the spare disk, and the address mapping table is dynamically updated with the host device before an automatic rebuild command is indicated to the SSD.

[0051] In the example embodiment, striped data indicates the addresses of consecutive segments of logically ordered data stored at each SSD.

[0052] Referring now to the accompanying drawings, in which similar reference numerals denote corresponding features throughout the drawings, some exemplary embodiments are shown.

[0053] Figure 1 This is an example of a traditional NVM express over Fabrics (NVMf) all-flash array.

[0054] See Figure 1 An all-flash array, such as an All Flash Array (AFA), can comprise disk groups (i.e., Just Bunch of Flash (JBOF)), where each JBOF includes multiple solid-state drives (SSDs). The JBOFs are connected together via a Fibre Channel switch. In the event that one of the SSDs encounters an I / O error (e.g., a single disk failure), the host device can enter maintenance mode. In maintenance mode, the host device can reconstruct lost data by manually reading data from each of the multiple SSDs. However, performing this reconstruction operation incurs significant overhead for the host device, which can adversely affect its overall performance.

[0055] Figure 2 This is a block diagram of a host device 100 coupled to multiple SSDs in a RAID data storage system according to an example embodiment disclosed herein.

[0056] A RAID data storage system may include a host device 100 and multiple SSDs. Each of the multiple SSDs can be configured to receive read and / or write requests from the host device 100. Furthermore, the multiple SSDs can be considered as data storage locations, which can be addressed as rows and columns in an array.

[0057] In an example embodiment, host device 100 includes an automatic rebuild engine 110, a snapshot engine 120, an automatic error correction engine 130, a communicator 140, a processor 150, a memory 160, and an I / O error management engine 170.

[0058] IO error management engine

[0059] In the example embodiment, the IO error management engine 170 is configured to detect the occurrence of an IO error in response to the host device 100 being unable to perform an input / output action (such as reading data, copying data, etc.) when the host device 100 attempts to access at least one SSD in the RAID data storage group. IO errors may also be due to the failure of one SSD in the RAID data storage system. An IO error can be, for example, a latent sector error (LSE), which occurs when a given sector within an SSD or the entire SSD within the RAID data storage system becomes inaccessible. Due to an LSE, a read or write operation may not be possible on the given sector. Furthermore, uncorrectable error correction code (ECC) errors may exist.

[0060] Furthermore, the IO error management engine 170 is also configured to detect whether an IO error corresponds to a failure of at least one of the multiple SSDs. When it is determined that an IO error corresponds to a failure of at least one of the multiple SSDs, the IO error management engine 170 can transfer control to the automatic rebuild engine 110. Conversely, when it is determined that an IO error does not correspond to a failure of at least one of the multiple SSDs, the IO error management engine 170 can transfer control to the automatic error correction engine 130.

[0061] In addition, the IO error management engine 170 is configured to receive IO error correction completion commands from each SSD. When an IO error does not correspond to a failure of at least one of the multiple SSDs, the IO error correction completion command is an automatic error correction completion command. When an IO error corresponds to a failure of at least one of the multiple SSDs, the IO error correction completion command is an automatic rebuild completion command.

[0062] Automatic engine rebuild

[0063] In the example embodiment, the automatic rebuild engine 110 is configured to detect failure of at least one of a plurality of SSDs and configure an address mapping table including striped data at a spare SSD. The spare SSD can be used for disk imaging, backup and recovery, archiving and retrieving archived data, and data migration from one SSD to another.

[0064] Furthermore, the automatic rebuild engine 110 is configured to send an automatic rebuild command to each of the multiple SSDs to perform an automatic rebuild operation. Additionally, the automatic rebuild engine 110 waits for the SSDs to complete the automatic rebuild operation. The automatic rebuild command contains information about the spare SSD. The address mapping table includes striped data and is configured in the controller storage buffer (CMB) of the spare SSD. The host device 100 can dynamically update the address mapping table before sending the automatic rebuild command to the SSD. The striped data in the address mapping table indicates the addresses of consecutive segments of logically ordered data stored at each SSD.

[0065] Snapshot Engine

[0066] In the example embodiment, snapshot engine 120 is configured to enable snapshot features for at least one of a plurality of SSDs to create snapshots of an address mapping table. Furthermore, snapshot engine 120 is also configured to send snapshot versions and timestamps to at least one SSD to retrieve matching snapshot data from the address mapping table. Snapshot engine 120 is also configured to receive snapshot data from at least one SSD based on the snapshot version and timestamp. The address mapping table includes snapshot data, timestamps, and snapshot versions of at least one SSD.

[0067] Automatic correction engine

[0068] In the example embodiment, the autocorrect engine 130 is configured to include metadata information about IO errors in the autocorrect request. Furthermore, the autocorrect engine 130 is also configured to send autocorrect commands to each of the multiple SSDs to perform the autocorrect operation. Additionally, the autocorrect engine 130 waits for the SSDs to complete the autocorrect operation.

[0069] In the example embodiment, the communicator 140 is configured to communicate with, for example, other applications in a cloud system, a central server, and / or host device 100. Protocols used for communication may include, for example, Bluetooth, Near Field Communication (NFC), ZigBee, RuBee, and Wireless Local Area Network (WLAN) functions.

[0070] In an example embodiment, processor 150 is configured to interact with hardware components such as automatic rebuild engine 110, snapshot engine 120, automatic error correction engine 130, communicator 140, memory 160, and I / O error management engine 170.

[0071] In some example embodiments, memory 160 may contain instructions that, when executed by processor 150, configure processor 150 as a dedicated processor to perform the functions of one or more of the automatic rebuild engine 110, snapshot engine 120, automatic error correction engine 130, and communicator 140. For example, as discussed in more detail below, the dedicated processor may be configured to improve the functionality of the RAID data storage system by initiating a recycling process and offloading the remaining recycling process to SSDs, and / or initiating a snapshot process and offloading the remaining snapshot process to multiple SSDs, thereby reducing the processing time and power requirements of host device 100.

[0072] In an example embodiment, memory 160 may include a non-volatile storage element. Examples of such a non-volatile storage element may include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. Additionally, in some examples, memory 160 may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term "non-transitory" should not be construed as meaning that memory 160 is non-removable. In some examples, a non-transitory storage medium may store data that changes over time (e.g., in random access memory (RAM) or a cache).

[0073] Although Figure 2 The components of host device 100 are shown, but it should be understood that the example embodiment is not limited thereto. In other example embodiments, host device 100 may include fewer or more components. Furthermore, the labels or names of components are for illustrative purposes only and do not limit the example embodiment. One or more components may be combined to perform the same or substantially similar functions to control the operation of a RAID data storage system.

[0074] Figure 3 This is a block diagram of an SSD 200 coupled to a host device 100 in a RAID data storage system according to an example embodiment disclosed herein, the RAID data storage system including multiple solid-state drives (SSDs).

[0075] See Figure 3The SSD 200 uses flash memory cells. Flash memory cells maintain a binary value based on the range of electrons captured and stored in a floating gate. A completely erased flash memory cell stores no electrons or stores a minimal number of electrons in the floating gate. Specific binary values, such as binary 1 for single-level cell (SLC) flash memory, are associated with erased flash memory cells. Multi-level cell (MLC) flash memory has a binary value of 11 associated with erased flash memory cells. After a voltage above a given threshold voltage is applied to the control gate within the flash memory cell, the flash memory cell captures a given range of electrons in the floating gate.

[0076] In an example embodiment, the SSD 200 includes an automatic rebuild engine 210, a snapshot engine 220, an automatic error correction engine 230, a communicator 240, a processor 250, and a memory 260.

[0077] SSDs can include storage data to be modified and accessed by end users, as well as inter-device error correction code (ECC) data. Inter-device ECC data can be parity information generated from other SSDs in a RAID data storage system. For example, inter-device ECC data can be parity information used in a RAID data storage system.

[0078] Automatic engine rebuild

[0079] In an example embodiment, the automatic rebuild engine 210 is configured to receive an automatic rebuild command from the host device 100 for performing an automatic rebuild operation. The automatic rebuild command may include information about the spare SSDs in the JBOF of the RAID data storage system. Furthermore, the automatic rebuild engine 210 is also configured to read striped data stored in the address mapping table of the spare SSDs and recover lost data by performing an automatic rebuild operation without any intervention from the host device 100. The rebuild operation includes retrieving data from multiple SSDs other than the failed SSD and determining parity for recovering the lost data. Additionally, once the automatic rebuild operation is complete, the automatic rebuild engine 210 is configured to send an automatic rebuild complete command to the host device 100. When at least one SSD from a plurality of SSDs in the RAID data storage system fails and data from the failed SSD must be recovered, each SSD in the RAID data storage system receives an automatic rebuild command from the host device 100.

[0080] Snapshot Engine

[0081] In the example embodiment, snapshot engine 220 is configured to determine a match between the snapshot version and timestamp of snapshot data in the address mapping table received from host device 100. Furthermore, snapshot engine 220 is also configured to trigger the creation of a snapshot of the address mapping table by all SSDs of the plurality of SSDs in the RAID data storage system in response to the detection of a match. The address mapping table includes snapshot data, timestamps, and snapshot versions of the RAID data storage system. Host device 100 enables snapshot functionality for all SSDs of the plurality of SSDs in the RAID data storage system. However, host device 100 does not create snapshots or offload snapshot creation features to all SSDs in the RAID data storage system.

[0082] In another example embodiment, snapshot engine 220 is configured to determine the number of free blocks and detect whether the snapshot frequency meets garbage collection (GC) criteria. Upon determining that the GC criteria are met, snapshot engine 220 is configured to initiate a GC operation. The GC operation erases dirty data from at least one SSD to increase the number of free blocks available for storing new data. Dirty data is data that has been stored in data blocks for a long time and is not used by any application in the RAID data storage system. Therefore, dirty data is used for snapshots.

[0083] In the example embodiment, the auto-correction engine 230 is configured to receive an auto-correction request from the host device 100 for performing an auto-correction operation. The auto-correction request includes information about I / O errors. Furthermore, the auto-correction engine 230 is configured to recover data from a failed SSD by performing an auto-correction operation based on I / O errors. The auto-correction operation includes reading data from the failed SSD using peer-to-peer communication based on metadata received from the host device 100, and calculating parity for recovering lost data from the failed SSD. Additionally, the auto-correction engine 230 is also configured to send an auto-correction completion command to the host device 100 after completing the auto-correction operation at the end of the SSD 200.

[0084] In the example embodiment, the communicator 240 is configured to communicate with, for example, other applications in a cloud system, a central server, and host device 100. Protocols used for communication may include, for example, Bluetooth, Near Field Communication (NFC), ZigBee, RuBee, and Wireless Local Area Network (WLAN) functions.

[0085] In an example embodiment, processor 250 is configured to interact with hardware elements such as automatic rebuild engine 210, snapshot engine 220, automatic error correction engine 230, communicator 240, and memory 260.

[0086] In some example embodiments, memory 260 may contain instructions that, when executed by processor 250, configure processor 250 as a dedicated processor to perform the functions of one or more of the automatic rebuild engine 210, snapshot engine 220, automatic error correction engine 230, and communicator 240. For example, as discussed in more detail below, the dedicated processor may be configured to reduce the processing time and power requirements of host device 100 by improving the functionality of the RAID data storage system after host device 100 initiates the recycling process, performing the remaining recycling process, and / or performing the remaining snapshot process after host device 100 initiates the snapshot process.

[0087] In example embodiments, memory 260 may include a non-volatile storage element. Examples of such a non-volatile storage element may include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. Additionally, in some examples, memory 260 may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term "non-transitory" should not be construed as meaning that memory 260 is non-removable. In some examples, memory 260 is configured to store a larger amount of information than a standard memory. In some examples, a non-transitory storage medium may store data that changes over time (e.g., in random access memory (RAM) or a cache).

[0088] although Figure 3 The hardware components of the SSD 200 are shown, but it should be understood that the example embodiment is not limited thereto. In other example embodiments, the SSD 200 may include fewer or more components. Furthermore, the labels or names of the components are for illustrative purposes only and do not limit the scope of the example embodiment. One or more components may be combined together to perform the same or substantially similar functions of controlling the operation of a RAID data storage system.

[0089] Figure 4 This is a flowchart illustrating a method for initiating an I / O error correction operation by a host device 100 according to an example embodiment disclosed herein.

[0090] See Figure 4 In operation 402, the host device 100 detected an I / O error. For example, in... Figure 2 In the host device 100 shown, the IO error management engine 170 is configured to detect IO errors.

[0091] In operation 404, host device 100 detects whether the I / O error corresponds to a failure of at least one of the multiple SSDs. For example, in... Figure 2In the host device 100 shown, the IO error management engine 170 is configured to detect whether an IO error corresponds to a failure of at least one of the multiple SSDs.

[0092] I / O error

[0093] In response to the detection of an IO error that does not correspond to a failure of at least one of the multiple SSDs, in operation 406, host device 100 configures an automatic error correction request that includes metadata information about the IO error. For example, in... Figure 2 In the host device 100 shown, the autocorrect engine 130 can be configured to configure autocorrect requests that include metadata information about IO errors. This metadata information is used to perform peer-to-peer communication via the SSD for autocorrect.

[0094] In operation 408, host device 100 sends an auto-correction request to each of the multiple SSDs 200 to perform an auto-correction operation. For example, in... Figure 2 In the host device 100 shown, the autocorrect engine 130 can be configured to send an autocorrect request to each of the multiple SSDs 200 to perform an autocorrect operation.

[0095] In operation 410, in response to the SSD completing IO error correction, host device 100 receives an IO error correction completion command from each SSD. For example, in... Figure 2 In the host device 100 shown, the IO error management engine 170 is configured to receive IO error correction completion commands from each SSD.

[0096] SSD failure

[0097] In response to the detection of an IO error corresponding to a failure of at least one of the multiple SSDs, in operation 412, the host device 100 detects a failure from at least one of the multiple SSDs. For example, in... Figure 2 In the host device 100 shown, the automatic rebuild engine 110 can be configured to detect failures of at least one SSD from a plurality of SSDs.

[0098] In operation 414, host device 100 is configured with an address mapping table that includes striped data at the spare SSD. For example, in... Figure 2 In the host device 100 shown, the automatic rebuild engine 110 can be configured to configure an address mapping table that includes striped data at the spare SSD.

[0099] In operation 416, host device 100 sends an automatic rebuild command to each of the multiple SSDs to perform an automatic rebuild operation. For example, in... Figure 2In the host device 100 shown, the automatic rebuild engine 110 can be configured to send automatic rebuild commands to each of the multiple SSDs to perform an automatic rebuild operation.

[0100] In operation 410, in response to the SSD performing an automatic rebuild operation, host device 100 receives an IO error correction completion command from each SSD. For example, in... Figure 2 In the host device 100 shown, the IO error management engine 170 is configured to receive IO error correction completion commands from each SSD.

[0101] Various actions, acts, blocks, steps, etc., in the method can be executed in the order they are presented, in different orders, or simultaneously. Furthermore, in some example embodiments, some of these actions, acts, blocks, steps, etc., may be omitted, added, modified, or skipped without departing from the scope of the example embodiments.

[0102] Figure 5 This is a flowchart illustrating a method for recovering data by performing automatic error correction operations by at least one SSD 200 according to an example embodiment disclosed herein.

[0103] refer to Figure 4 and 5 In operation 502, SSD 200 receives an autocorrect request from host device 100 for performing autocorrection operations. In operation 408, SSD 200 may receive an autocorrect request in response to host device 100 sending an autocorrect request. For example, in... Figure 3 In the SSD 200 shown, the autocorrect engine 230 can be configured to receive autocorrect requests from the host device 100 to perform autocorrect operations.

[0104] In the event of Operation 504, the SSD 200 recovers the data by performing automatic error correction based on the metadata provided in the automatic error correction request. For example, in situations such as... Figure 3 In the SSD 200 shown, the auto-correction engine 230 can be configured to recover data by performing auto-correction operations based on metadata provided in the auto-correction request. The auto-correction operation involves reading data from multiple SSDs in the RAID group, excluding the SSD with the IO error, and recovering the data using parity information.

[0105] In operation 506, SSD 200 sends an auto-correction completion command to host device 100. This auto-correction completion command may correspond to the IO error correction completion command received by host device 100 in operation 410. For example, in... Figure 3In the SSD200 shown, the autocorrect engine 230 can be configured to send an autocorrect completion command to the host device 100.

[0106] Various actions, movements, blocks, steps, etc., in the method can be executed in the order they are presented, in different orders, or simultaneously. Furthermore, in some example embodiments, some of these actions, movements, blocks, steps, etc., may be omitted, added, modified, or skipped without departing from the scope of the example embodiments.

[0107] Figure 6 This is a flowchart illustrating a method for recovering lost data without intervention from host device 100 by performing an automatic reconstruction operation, according to an example embodiment disclosed herein.

[0108] See Figure 6 In operation 602, SSD 200 receives an automatic rebuild command from host device 100 for performing an automatic rebuild operation. The automatic rebuild command may correspond to the automatic rebuild command sent by host device 100 in operation 416. For example, in... Figure 3 In the SSD 200 shown, the automatic rebuild engine 210 can be configured to receive automatic rebuild commands from the host device 100 for performing automatic rebuild operations.

[0109] In operation 604, SSD 200 receives striped data from the address mapping table stored on the spare SSD. For example, in... Figure 3 In the SSD 200 shown, the automatic rebuild engine 210 can be configured to receive striped data stored in the address mapping table of the spare SSD.

[0110] In operation 606, SSD 200 recovers lost data by performing an automatic rebuild operation without intervention from host device 100. For example, in... Figure 3 In the SSD 200 shown, the automatic rebuild engine 210 can be configured to recover lost data by performing automatic rebuild operations without intervention from the host device 100.

[0111] In operation 608, SSD 200 sends an automatic rebuild complete command to host device 100. The automatic rebuild complete command may correspond to the IO error correction complete command received by host device 100 in operation 410. For example, in... Figure 3 In the SSD200 shown, the automatic rebuild engine 210 can be configured to send an automatic rebuild complete command to the host device 100.

[0112] Various actions, blocks, steps, etc., in the method can be executed in the order they are presented, in different orders, or simultaneously. Furthermore, in some example embodiments, some of these actions, blocks, steps, etc., may be omitted, added, modified, or skipped without departing from the scope of the example embodiments.

[0113] Figure 7 This is a flowchart illustrating a method for receiving snapshot data from at least one SSD 200 by a host device 100 according to an example embodiment disclosed herein.

[0114] refer to Figure 7 In operation 702, host device 100 enables snapshot features for at least one SSD 200 from multiple SSDs to manage snapshots of the address mapping table. For example, in... Figure 2 In the host device 100 shown, the snapshot engine 120 can be configured to enable snapshot features for at least one SSD 200 from multiple SSDs to manage snapshots of the address mapping table.

[0115] In operation 704, host device 100 sends the snapshot version and timestamp to at least one SSD to retrieve snapshot data from the address mapping table. For example, in... Figure 2 In the host device 100 shown, the snapshot engine 120 can be configured to send snapshot versions and timestamps to at least one SSD to retrieve snapshot data from an address mapping table.

[0116] In operation 706, host device 100 receives snapshot data from at least one SSD based on the snapshot version and timestamp. For example, in... Figure 2 In the host device 100 shown, the snapshot engine 120 can be configured to receive snapshot data from at least one SSD based on the snapshot version and timestamp.

[0117] Various actions, movements, blocks, steps, etc., in the method can be executed in the order they are presented, in different orders, or simultaneously. Furthermore, in some example embodiments, some of these actions, movements, blocks, steps, etc., may be omitted, added, modified, or skipped without departing from the scope of the example embodiments.

[0118] Figure 8 This is a flowchart illustrating a method for triggering the creation of an address mapping table by at least one SSD 200 according to an example embodiment disclosed herein.

[0119] See Figure 8 In operation 802, SSD 200 determines the match between the snapshot version and the timestamp. The snapshot version and timestamp may correspond to the snapshot version and timestamp sent by host device 100 in operation 704.

[0120] For example, in such Figure 3 In the SSD 200 shown, the snapshot engine 220 can be configured to determine the match between the snapshot version and the timestamp.

[0121] In Operation 804, the SSD 200 triggers a snapshot of the address mapping table in response to the detection of a match. For example, in... Figure 3 In the SSD 200 shown, the snapshot engine 220 can be configured to trigger the creation of an address mapping table in response to the detection of a match.

[0122] Various actions, movements, blocks, steps, etc., in the method can be executed in the order they are presented, in different orders, or simultaneously. Furthermore, in some example embodiments, some of these actions, movements, blocks, steps, etc., may be omitted, added, modified, or skipped without departing from the scope of the example embodiments.

[0123] Figure 9 This is an example illustrating automatic reconstruction operations in JBOF according to an example embodiment disclosed herein.

[0124] See Figure 9 In a RAID group, a JBOF can include multiple SSDs, at least one of which can be a spare SSD. For example, a JBOF can include five SSDs: SSD1, SSD2, SSD3, SSD4, and SSD5. Figure 9 As shown, SSD5 can be a spare SSD. SSDs in JBOF can have direct network connections via NVMe, fiber optic switches, connector switches, etc.

[0125] At least one SSD in the JBOF may fail. For example, see reference. Figure 9 SSD1 may fail.

[0126] In traditional methods and systems, when one SSD in a JBOF fails (e.g., SSD1), the host device 100 enters maintenance mode, where only read options are supported. In maintenance mode, the host device 100 reconstructs the data lost from SSD1 by manually reading data from the other SSDs (i.e., SSD2, SSD3, and SSD4). The host device 100 recovers data from SSD1 by performing operations such as XOR on the data in SSD2, SSD3, and SSD4; and by calculating parity values, ECC algorithms, or any other suitable algorithms. Furthermore, the host device 100 writes the recovered data from SSD1 to a spare SSD, i.e., SSD5. However, the process of recovering data from the failed SSD involves the host device 100 performing a recovery procedure.

[0127] Unlike traditional methods and systems, in one or more example embodiments, host device 100 performs a limited role in initiating the recycling process. Furthermore, the recycling process is executed independently by the SSD, thereby reducing the processing time and power requirements of host device 100.

[0128] Initially, host device 100 configures the RAID group and address mapping table in the Controller Storage Buffer (CMB) of the spare SSD (i.e., SSD5). Host device 100 detects that SSD1 has failed. After the failure of SSD1, SSD5 (the spare SSD) is used to replace SSD1 by writing the lost data blocks from SSD1 to SSD5. The reconstruction process recreates the lost data and / or redundant blocks in the stripe through degraded reads for lost data blocks and redundancy recalculation for lost redundant blocks. In response to the detection that SSD1 has failed, host device 100 shares the stripe address mapping to the CMB area of ​​SSD5.

[0129] The address mapping table includes striped data that indicates the addresses of consecutive segments of logically ordered data stored at each of the four SSDs. Furthermore, host device 100 sends an automatic rebuild command to SSD2, SSD3, SSD4, and SSD5 to perform an automatic rebuild operation. The automatic rebuild command sent by host device 100 also includes details about the spare SSD, SSD5. Upon receiving the automatic rebuild command from host device 100 to perform the automatic rebuild operation, SSD5 reads data from SSD2, SSD3, and SSD4. Furthermore, the lost data is recovered by performing the automatic rebuild operation without any intervention from host device 100. The automatic rebuild operation includes performing an XOR operation on the data stored in SSD2, SSD3, and SSD4 and calculating parity values ​​to recover the lost data. Upon completion of the automatic rebuild operation, an automatic rebuild completion command is sent to host device 100 for SSD5 to confirm.

[0130] Figure 10 This is an example of a snapshot showing an address mapping table created by at least one SSD according to an example embodiment disclosed herein.

[0131] Garbage collection (GC) is a process in which storage locations in an SSD are freed from dirty data and made available for reuse by the host device. Without garbage collection, all storage locations would eventually appear to be in use and may become unavailable for further storage allocation.

[0132] Dirty data is data in a storage location that has been overwritten by updated data and may no longer be needed by any application. However, dirty data is used for snapshots. In traditional methods and systems, the garbage collection process is performed by host device 100, which involves significant overhead and adversely affects the overall performance of host device 100. A snapshot is the process of determining a fully usable copy of a specified dataset, which involves copying the data at a specific point in time (timestamp) provided by host device 100. Host device 100 also updates the address mapping between logical and physical address data in the address mapping table. In addition, host device 100 creates a new snapshot of the address mapping table.

[0133] For example, the system may include primary storage SSDs and spare SSDs, such as Figure 10 As shown. The primary storage SSD can be located in the JBOF to which the primary storage SSD belongs, or in a different JBOF.

[0134] In conventional methods and systems, host device 100 participates in the garbage collection process, namely, obtaining the differences between updated data and past data; and also storing the difference data in the spare storage SSD. Furthermore, host device 100 is also involved in moving data into and out of the spare storage SSD.

[0135] Unlike traditional methods and systems, in one or more example embodiments, host device 100 does not perform snapshot processing. Instead, host device 100 only initiates a snapshot process, and multiple SSDs perform the snapshot process.

[0136] Host device 100 enables snapshot features for the standby storage SSD to manage snapshots of the address mapping table. Furthermore, host device 100 sends snapshot versions and timestamps to the standby storage SSD to receive snapshot data from the address mapping table. The standby storage SSD can also receive volume IDs, logical or virtual addresses associated with requests, snapshot IDs, sector numbers, etc. The address mapping table includes snapshot data, timestamps, and snapshot versions of the main storage SSD. Moreover, the address mapping table resides within the standby storage SSD.

[0137] Upon receiving the snapshot version and timestamp, the standby storage SSD identifies the number of free blocks and determines whether the snapshot frequency meets the GC criteria, then initiates a GC operation. Furthermore, the standby storage SSD determines a match between the snapshot version and the timestamp received from host device 100, and creates a snapshot of the address mapping table in response. The address mapping table stores snapshot data for the SSDs in the RAID group, which also includes the primary storage SSD, timestamps, and snapshot versions. Whenever updated data becomes available, the primary storage SSD transfers dirty data to the standby storage SSD in the background without any intervention from host device 100. When host device 100 needs a snapshot of the address mapping table, host device 100 only needs to enable snapshot functionality for the primary storage SSD.

[0138] If the GC operation is independent of whether snapshot features are enabled on the primary storage SSD, a GC operation running on the primary storage SSD can erase critical data from the primary storage SSD for which no backup has yet been created. Therefore, host device 100 must ensure that GC operations are not performed on any SSD for which snapshot features are enabled (the primary storage SSD in this example) until a backup of the critical data is created. Furthermore, once a backup of the critical data in the primary storage SSD is created, a GC operation can be performed on the primary storage SSD to erase the critical data (which may be dirty data, as no application needs it).

[0139] The foregoing description of some exemplary embodiments will so fully reveal the general nature of the exemplary embodiments herein that others can readily modify and / or adapt them to various applications by applying present knowledge, without departing from these exemplary embodiments, and thus, such adaptations and modifications should and are intended to be understood within the meaning and scope of equivalents of the disclosed exemplary embodiments. It should be understood that the wording or terminology used herein is for descriptive purposes and not for limitation. Therefore, although exemplary embodiments herein have been described with reference to some exemplary embodiments, those skilled in the art will recognize that the exemplary embodiments herein can be practiced with modifications within the spirit and scope of the exemplary embodiments as described herein.

Claims

1. A method of controlling operation of a redundant array of independent disks (RAID) data storage system, the RAID data storage system comprising a host device and a plurality of solid state drives (SSDs), the method comprising: detecting, by the host device, an IO error; determining, by the host device, whether the IO error corresponds to a failure of at least one of the plurality of SSDs; and in response to the IO error corresponding to the failure of the at least one of the plurality of SSDs, configuring, by the host device, an address mapping table to cause the address mapping table to include stripe data at a spare SSD, wherein the stripe data indicates addresses of contiguous segments of logically sequential data stored in respective ones of the plurality of SSDs, sending, by the host device, an auto-rebuild command to each of the plurality of SSDs, the auto-rebuild command instructing each of the plurality of SSDs to perform an auto-rebuild operation, such that the auto-rebuild command includes information about the spare SSD, and receiving, by the host device, an IO error correction completion command from each of the plurality of SSDs, wherein the auto-rebuild operation comprises forming a data path for the auto-rebuild operation between the plurality of SSDs and the spare SSD, thereby bypassing the host device. in response to determining that the IO error does not correspond to the failure of the at least one of the plurality of SSDs, the method comprising:

2. The method of claim 1, wherein, configuring, by the host device, an auto-error correction request to cause the auto-error correction request to include metadata information about the IO error; and sending, by the host device, the auto-error correction request to each of the plurality of SSDs to perform an auto-error correction operation. the plurality of SSDs belong to a single RAID group.

3. The method of claim 1, wherein, the stripe data in the address mapping table is stored in a controller memory buffer (CMB) of the spare SSD, and wherein the method further comprises:

4. The method of claim 1, wherein, dynamically updating, by the host device, the address mapping table prior to sending the auto-rebuild command to the plurality of SSDs.

5. A method of controlling operation of a redundant array of independent disks (RAID) data storage system, the RAID system comprising a host device and a plurality of solid state drives (SSDs), the method comprising: in response to an IO error corresponding to a failure of at least one of the plurality of SSDs, receiving, by each of the plurality of SSDs, an auto-rebuild command from the host device, the auto-rebuild command requesting performance of an auto-rebuild operation, the auto-rebuild command including information about a spare SSD of the plurality of SSDs; reading, by each of the plurality of SSDs, stripe data from an address mapping table of the spare SSD, wherein the stripe data indicates addresses of contiguous segments of logically sequential data stored in respective ones of the plurality of SSDs; retrieving, by each of the plurality of SSDs, lost data by performing the auto-rebuild operation in cooperation with one another without intervention from the host device; and after performance of the auto-rebuild operation, sending, by each of the plurality of SSDs, an auto-rebuild completion command to the host device, ​ wherein the auto-rebuild operation includes forming a data path for the auto-rebuild operation between the plurality of SSDs and the spare SSD, thereby bypassing the host device.

6. The method of claim 5, wherein, Each of the plurality of SSDs is configured to receive an auto-rebuild command from the host device and information of the spare SSD in response to a failure of the at least one SSD.

7. The method of claim 5, wherein, The at least one SSD reads the stripe data from an address mapping table of the spare SSD through peer-to-peer communication with other SSDs of the plurality of SSDs, wherein the spare SSD receives the stripe data from the host device through a controller memory buffer (CMB).

8. The method of claim 7, wherein, The CMB is associated with the spare SSD.

Images