Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/16—Error detection or correction of the data by redundancy in hardware
  • G06F11/1658—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
  • G06F11/1662—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit the resynchronized component or unit being a persistent storage device
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/16—Error detection or correction of the data by redundancy in hardware
  • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
  • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
  • G06F11/2094—Redundant storage or storage space
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
  • G06F12/16—Protection against loss of memory contents
• • G—PHYSICS
  • G11—INFORMATION STORAGE
  • G11C—STATIC STORES
  • G11C29/00—Checking stores for correct operation ; Subsequent repair; Testing stores during standby or offline operation
  • G11C29/52—Protection of memory contents; Detection of errors in memory contents
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
  • G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data

Definitions

• SSDs Solid state drives
• NAND technologies that the drives are based on have a limited number or program/erase cycles.
• SSDs may reach a point where an erase cycle fails to reset a NAND flash block to a writable state. Such an SSD may be said to be failed.
• Current disk array controllers designed to handle traditional spindle-based disk drives may employ failure modes that affect both reading and writing, rendering the drives useless.
• SSD may employ a read-only failure mode that allows the drive to execute read commands successfully even though write commands result in a failure.
• a read-only failure mode that allows the drive to execute read commands successfully even though write commands result in a failure.
• controllers can not effectively utilize the read-only failure mode of SSDs.
• the present disclosure is directed to a system and method for recovering solid state drive (SSD) data.
• SSD solid state drive
• a method for recovering solid state drive (SSD) data may comprise: detecting a failed SSD comprising one or more data blocks; receiving a request to write data to the one or more data blocks of the failed SSD; writing the data to one or more data blocks of an operational drive; and rebuilding the failed SSD from the failed SSD and the one or more data blocks of the operational drive.
• SSD solid state drive
• a system for recovering solid state drive (SSD) data may comprise: means for detecting a failed SSD comprising one or more data blocks; means for receiving a request to write data to the one or more data blocks of the failed SSD; means for writing the data to one or more data blocks of an operational drive; and means for rebuilding the failed SSD from the failed SSD and the one or more data blocks of the operational drive.
• FIG. 1 shows a high-level block system for recovering solid state drive
• FIG. 2 shows a process for recovering solid state drive (SSD) data.
• FIG. 3 shows a process for recovering solid state drive (SSD) data.
• FIG. 4 shows a process for recovering solid state drive (SSD) data.
• FIG. 5 shows a process for recovering solid state drive (SSD) data.
• FIG. 6 shows a process for recovering solid state drive (SSD) data.
• FIG. 7A shows an SSD configuration.
• FIG. 7B shows a look-up table configuration.
• FIG. 8A shows an SSD configuration.
• FIG. 8B shows a look-up table configuration.
• FIG. 1 illustrates an example system in which one or more technologies may be implemented.
• a data storage system 100 comprising a computing device 101 , an array controller 102, and a drive array 103 is shown.
• the array controller 102 may include drive management circuitry/software whereby the array controller 102 can process read/write requests of the computing device 101 accessing various drives of the drive array 103.
• the drive array 103 may include a one or more drives including at least one SSD 104 and at least one operational drive 105.
• the operational drive 105 may be an SSD or a hard disk drive (HDD).
• FIG. 2 illustrates an operational flow 200 representing example operations related to SSD recovery.
• discussion and explanation may be provided with respect to the above-described examples of FIG. 1 , and/or with respect to other examples and contexts.
• the operational flows may be executed in a number of other environments and contexts, and/or in modified versions of FIG. 1.
• the various operational flows are presented in the sequence(s) illustrated, it should be understood that the various operations may be performed in other orders than those that are illustrated, or may be performed concurrently.
• the operation 210 illustrates detecting a failed SSD comprising one or more data blocks.
• the array controller 102 may detect that the drive array 103 is no longer capable of processing write instructions to a data block 106 of the drive array 103.
• Operation 220 illustrates receiving a request to write data to the one or more data blocks of the failed SSD.
• the array controller 102 may receive a request from the computing device 101 to write data to the data block 106 of the SSD 104.
• Operation 230 illustrates writing the data to one or more data blocks of an operational drive.
• the array controller 102 may cause the drive array 103 to write data to a data block 107 of the operational drive 105.
• Operation 240 illustrates rebuilding the failed SSD from the failed SSD and the one or more data blocks of the operational drive.
• the array controller 102 may rebuild the SSD 104 from the current contents of the SSD 104 and the operational drive 105 to the replacement SSD 111.
• FIG. 3 illustrates alternative embodiments of the example operational flow 200 of FIG. 2.
• FIG. 3 illustrates example embodiments where the detecting operation 210 may include at least one additional operation. Additional operations may include an operation 302.
• Operation 302 illustrates detecting a failed write directed to one or more data blocks of the SSD.
• the array controller 102 may detect that the drive array 103 is no longer capable of processing write instructions directed to a data block 106 of the SSD 104.
• FIG. 4 illustrates alternative embodiments of the example operational flow 200 of FIG. 2.
• FIG. 4 illustrates example embodiments where the operational flow 200 may include at least one additional operation. Additional operations may include an operation 402 and/or an operation 404.
• Operation 402 illustrates writing the data to one or more data blocks of an operational drive according to a redirect-on-write snapshot methodology.
• the array controller 102 may cause the SSD 104 to place newly written data in a different location than previously written copy of the same data.
• the operational drive 105 may be an SSD that has been erased and is ready to be written.
• look-up table 108A may maintain the mappings of the data blocks to their respective flash blocks and pages.
• the array controller 102 may receive a write command for segments 210 and 211 of the SSD 104. Should one or more data blocks of the SSD 104 be detected as failed, the data storage system 100 may employ a redirect-on-write snapshot methodology to maintain the integrity of data in the SSD 104. [0020] As shown in FIG. 8A 1 the array controller 102 may accept the new data for segments 210 and 211 and write it to pre-erased areas of the operational drive 105. The SSD 104 may remain unchanged ( Figure 8A is modified to show that the data for blocks 210 and 211 in SSD 104 is "old" data).
• the state of the operational drive 105 is as shown in FIG. 8A.
• the old copies of data segments 210 and 211 may remain in the SSD 104 until the entire SSD 104 is reclaimed and erased in preparation for reuse.
• the look-up table 108A in the array controller 102 may be updated to reflect the new addresses for data segments 210 and 211 and appear as shown in Figure 8B.
• Operation 404 illustrates updating one or more look-up tables comprising data block mappings for the failed SSD and an operational SSD.
• the array controller 102 may include one or more look-up tables (e.g. look-up table 108A and look-up table 108B) which maintain mapping lists of memory block elements and their respective flash addresses in the SSD 104 and/or the operational drive 105.
• the SSD 104 may execute a redirect-on-write for every write command received, the SSD 104 may retain a previous copy of user data that can be used to reconstruct both current data or prior snapshot data at no loss in performance.
• the data storage system 100 may provide access to multiple point-in-time copies of the data stored in the device.
• the array controller 102 may receive a command to store a point in time copy of the data prior to the write of segments 210 and 211.
• the array controller 102 may retain a copy of the lookup table for addresses shown in Figure 9B in as the pointers to the addresses for the point in time copy in look-up table 108A.
• the current view of the data may be maintained in the second look-up table 108B.
• the array controller 102 may keep a copy of both tables so long as it has space for the snapshot and the snapshot is not ended via some other action.
• FIG. 5 illustrates alternative embodiments of the example operational flow 200 of FIG. 2.
• FIG. 5 illustrates example embodiments where the rebuilding operation 240 may include at least one additional operation. Additional operations may include an operation 502 and/or an operation 504.
• Operation 502 illustrates copying one or more data blocks of the failed SSD for which write requests have not been received to a replacement SSD.
• the array controller 102 may cause those portions of SSD 104 that have not been addressed by write requests (e.g. unmodified data block 109) to be copied to a data block 110 of a replacement SSD 111.
• Operation 504 illustrates copying the one or more data blocks of the operational drive to the replacement SSD.
• the array controller 102 may cause those portions of operational drive 105 which have been written in response to failed write operations directed to the SSD 104 (e.g. data block 107) to be copied to a data block 112 of the replacement SSD 111.
• FIG. 6 illustrates alternative embodiments of the example operational flow 200 of FIG. 2.
• FIG. 6 illustrates example embodiments where the operational flow 200 may include at least one additional operation. Additional operations may include an operation 610.
• Operation 610 illustrates redirecting a read request directed to the one or more data blocks of the operational drive to one or more data blocks of the replacement SSD.
• the operational drive 105 may comprise a HDD.
• the array controller 102 may maintain a pointer to the extent of data that has been written to the replacement SSD 111.
• the array controller 102 may direct the read request to the replacement SSD 111.
• the replacement SSD 111 may be able to service a potion of the IO stream that would have been serviced by the HDD operational drive 105 SSD 104 prior to its failure thereby maintaining an increased level of performance as compared to the situation where the IO was serviced by the HDD operational drive 105.
• Examples of a signal bearing medium include, but are not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a Compact Disc (CD), a Digital Video Disk (DVD), a digital tape, a computer memory, etc.; and a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link (e.g., transmitter, receiver, transmission logic, reception logic, etc.), etc.).
• a recordable type medium such as a floppy disk, a hard disk drive, a Compact Disc (CD), a Digital Video Disk (DVD), a digital tape, a computer memory, etc.
• a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link (e.g., transmitter, receiver, transmission logic, reception
• an implementer may opt for a mainly hardware and/or firmware vehicle; alternatively, if flexibility is paramount, the implementer may opt for a mainly software implementation; or, yet again alternatively, the implementer may opt for some combination of hardware, software, and/or firmware.
• any vehicle to be utilized is a choice dependent upon the context in which the vehicle will be deployed and the specific concerns (e.g., speed, flexibility, or predictability) of the implementer, any of which may vary.
• Those skilled in the art will recognize that optical aspects of implementations will typically employ optically-oriented hardware, software, and or firmware.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Quality & Reliability (AREA)
• Techniques For Improving Reliability Of Storages (AREA)
• Debugging And Monitoring (AREA)
• Signal Processing For Digital Recording And Reproducing (AREA)

Priority Applications (4)

Applications Claiming Priority (2)

Publications (1)

Family

ID=42172910

Family Applications (1)

Country Status (7)

Families Citing this family (28)

Citations (3)

Family Cites Families (19)

• 2008
  • 2008-11-18 US US12/313,205 patent/US8041991B2/en not_active Expired - Fee Related
• 2009
  • 2009-03-31 KR KR1020117011169A patent/KR20110091677A/ko active IP Right Grant
  • 2009-03-31 WO PCT/US2009/001986 patent/WO2010059173A1/en active Application Filing
  • 2009-03-31 JP JP2011536302A patent/JP2012509521A/ja not_active Ceased
  • 2009-03-31 EP EP20090827843 patent/EP2356658A4/en not_active Withdrawn
  • 2009-03-31 CN CN200980142288.3A patent/CN102197438B/zh not_active Expired - Fee Related
  • 2009-04-02 TW TW098110964A patent/TWI442225B/zh not_active IP Right Cessation

Patent Citations (3)

Also Published As

Similar Documents

Legal Events