Abstract:
A solid-state drive (SSD) is configured for dynamic resizing. When the SSD approaches the end of its useful life because the over-provisioning amount is nearing the minimum threshold as a result of an increasing number of bad blocks, the SSD is reformatted with a reduced logical capacity so that the over-provisioning amount may be maintained above the minimum threshold.

Description:
BACKGROUND 
     Recently, solid state drives (SSDs) have been adopted widely as it provides lower latency input-output operations (IOs) than rotating disk based drives. However, the acquisition costs of SSDs are comparatively higher, and the performance of SSDs degrades as the number of bad blocks in the SSDs increases over time. As a buffer against bad blocks that increase over time and to also provide a storage area that can be used for garbage collection and other system functions, SSDs are typically over-provisioned by a set amount. To give an example, an SSD that has a logical capacity of 100 GB, i.e., the capacity that is exposed as being usable capacity, may be initially over-provisioned by a predetermined amount, e.g., 20 GB. This predetermined amount is set to be larger than a minimum amount that is needed for functions such as garbage collection so that the SSD will not fail as long as the number of bad blocks remain below a certain limit. It should be recognized that the larger this predetermined over-provisioning amount becomes, the longer the useful life of the SSD will be. In addition, a larger over-provisioning amount improves the IOPS (IOs per second) performance of the SSD. However, the over-provisioning amount should not be set too large because it takes away from the useful capacity of the SSD. 
     SUMMARY 
     Embodiments provide an SSD that is configured for dynamic resizing. According to embodiments, when the SSD approaches the end of its useful life because the over-provisioning amount is nearing the minimum threshold as a result of an increasing number of bad blocks, the SSD is reformatted with a reduced logical capacity so that the over-provisioning amount may be maintained above the minimum threshold. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a drive connected to a host in which embodiments may be practiced. 
         FIG. 2  illustrates changes to a drive&#39;s over-provisioning percentage and logical capacity over time when embodiments are implemented. 
         FIG. 3  illustrates one example of a CDB for a first API employed in the method according to embodiments. 
         FIG. 4  graphically illustrates how much of the user data can be preserved while performing dynamic resizing according to embodiments. 
         FIG. 5  illustrates a communication flow between the host and the drive upon issuance of a second API employed in the method according to embodiments. 
         FIG. 6  illustrates an example data format for over-provisioning information that is returned from the drive to the host. 
         FIG. 7  is a flow diagram of steps carried out by the host and the drive during dynamic resizing according to embodiments. 
         FIG. 8  illustrates graphically a situation where a current over-provisioning amount is not sufficient. 
         FIG. 9  illustrates graphically an example where an over-provisioning amount is specified in the first API. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  is a drive (e.g., an SSD)  100  connected to a host  10  in which embodiments may be practiced. Host  10  is a computing device that issues IOs to drive  100  through standard storage interfaces such as iSCSI, SATA, PCIe, SAS, etc. and includes conventional components of a computer such as one or more processors, random access memory, a network interface, and a disk interface. In the embodiments illustrated herein, host  10  is further configured with a drive reconstruct software module  20  that resides in memory and executes on the processors to reconfigure drive  100  according to the method described below in conjunction with  FIG. 7 . 
     Drive  100  includes an interface  110 , e.g., an iSCSI interface, a SATA interface, a PCIe interface, or a SAS interface, a drive controller  120 , a random access memory (RAM)  130 , a high-speed data path  140 , which may be any high-speed bus known in the art, such as a double data rate (DDR) bus, a DDR2 bus, a DDR3 bus, or the like, and a flash memory device  150 . Drive controller  120  is configured to control the operation of drive  100 , and is connected to RAM  130  and flash memory device  150  via high-speed data path  140 . Drive controller  120  is also configured to control interface  110 . Some or all of the functionality of drive controller  120  may be implemented as firmware, application-specific integrated circuits, and/or a software application. RAM  130  is a volatile semiconductor memory device, such as a dynamic RAM (DRAM). RAM  130  is configured for use as a data buffer for SSD  140 , temporarily storing data received from host  10 . 
     In addition, drive controller  120  maintains a bad block map  135  in RAM  130 . Bad block map  135  includes addresses of blocks in flash memory device  150  that have been determined by driver controller  120  to be bad. Drive controller  120  may make this determination during reads and writes performed on blocks of flash memory device  150 , or during a partial or full scan for bad blocks performed on blocks of flash memory device  150 . 
     Flash memory device  150  is a non-volatile semiconductor storage, such as a NAND flash chip, that can be electrically erased and reprogrammed. For clarity, drive  100  is illustrated in  FIG. 1  to include a single flash memory device  150 , but in many embodiments, drive  100  includes multiple flash memory devices  150 . Flash memory device  150  includes a plurality of memory cells that are grouped into readable and writable pages, each page having a size of 4 KB to 16 KB. These pages are organized into memory blocks (typically 128 to 512 pages per block), the memory block representing the smallest erasable unit of flash memory device  150 . 
     Flash memory device  150  has an associated raw physical capacity. During a drive initialization process known as formatting, drive controller  120  configures flash memory device  150  with a logical capacity that is equal to the raw physical capacity minus a system area amount (typically a fixed amount) and a predetermined over-provisioning amount, which as described above is used as a buffer against bad blocks that increase over time and to also provide a storage area that can be used for garbage collection and other system functions.  FIG. 2  shows the relationship between the over-provisioned amount and the logical capacity of drive  100 . At time t 0 , when there are no bad blocks, the over-provisioned amount is at its predetermined level. However, as the number of bad blocks begins to increase at time t 1 , the over-provisioned amount begins to decrease. At time t 2 , the over-provisioned amount reaches a minimum threshold, and drive  100  is dynamically resized according to techniques described below. As a result of the dynamic resizing, the logical capacity decreases and the over-provisioned amount increases to the predetermined level. 
     To support dynamic resizing, drive  100  is configured with two application programming interfaces (APIs) that are exposed to host  10 . The first is the Reconstruct API, which has a single input parameter or two input parameters. One example of the Reconstruct API has a command descriptor block (CDB) shown in  FIG. 3 . If the first input parameter is 0, drive controller  120  executes the dynamic resizing without scanning flash memory device  150  for bad blocks. If the first input parameter is 1, drive controller  120  executes the dynamic resizing after a partial scan of flash memory device  150  for bad blocks. If the first input parameter is 2, drive controller  120  executes the dynamic resizing after a full scan of flash memory device  150  for bad blocks. Optionally, the predetermined over-provisioning amount may be overridden by the second input parameter when the second input parameter has a non-zero value. Upon receiving the Reconstruct API from host  10 , driver controller  120  returns an acknowledgement of receipt to host  10  and executes the process for dynamic resizing as described below in conjunction with  FIG. 7 . Other features of the Reconstruct API are as follows. User data is lost when this API is executed. Alternatively, the user data up to the amount of the resized logical capacity may be preserved as shown in  FIG. 4 . In addition, after the acknowledgement of this API, host  10  may not be able to detect drive  100  and commands from host  10  are not guaranteed to be executed. 
     The second API is the Get_Overprovisioning_information API. This API has no input parameters. The communication flow between host  10  and drive controller  120  upon issuance of this API by host  10  is schematically illustrated in  FIG. 5 . Upon receiving the Get_Overprovisioning_information API from host  10 , driver controller  120  reads the predetermined over-provisioning amount and the minimum over-provisioning amount for normal operation from drive metadata stored in RAM  130  and/or flash memory device  150 , and also computes the current over-provisioning amount according to the formula: current over-provisioning amount=raw physical capacity−current logical capacity−bad block capacity−system area amount. Then, driver controller  120  returns status (PASS or FAIL) to host  10  as an acknowledgement and thereafter returns the predetermined over-provisioning amount and the minimum over-provisioning amount to host  10  as over-provisioning information. One example data format for the predetermined over-provisioning amount and the minimum over-provisioning amount is illustrated in  FIG. 6 . 
       FIG. 7  is a flow diagram of steps carried out by host  10  and drive  100  during dynamic resizing according to embodiments. Steps  710 ,  720 ,  730 ,  740 , and  790  are carried out by host  10  through drive reconstruct software module  20 . Steps  715 ,  745 ,  750 ,  760 ,  770 , and  780  are carried out by drive  100 , in particular drive controller  120 . Although the steps of  FIG. 7  are described herein as performed by host  10  and drive  100 , it should be recognized that other systems, such as integrated host-drive systems, may implement the steps of  FIG. 7 . 
     The method of  FIG. 7  begins at step  710  where host  10  issues the Get_Overprovisioning_information API to drive  100 . This step may be executed once every hour, after a predetermined size of data has been written, after a predetermined percentage of the logical capacity is written, when drive  100  becomes idle, or when drive  100  is powered up. As a result, host  10  can recognize that drive  100  is approaching end-of-life in advance and can dynamically resize the logical capacity of drive  100  before drive  100  fails. Upon receipt of Get_Overprovisioning_information API from host  10 , drive controller  120  at step  715  reads the predetermined over-provisioning amount and the minimum over-provisioning amount for normal operation from drive metadata stored in RAM  170  and/or flash memory device  150 , and also computes the current over-provisioning amount according to the formula: current over-provisioning amount=raw physical capacity−current logical capacity−bad block capacity. The bad block capacity is determined based on the information stored in bad block map  135 . For example, if bad block map  135  indicates  100  blocks as being bad blocks and each block is 512 KB in size, the bad block capacity will be 5.12 MB. 
     At step  720 , host  10  receives the over-provisioning information including the predetermined over-provisioning amount, the minimum over-provisioning amount, and the current over-provisioning amount from drive  100 . Based on this, at step  730 , host  10  determines if the current over-provisioning amount is sufficient, e.g., greater than the minimum over-provisioning amount.  FIG. 8  illustrates graphically a situation where the current over-provisioning amount is not sufficient. When host  10  determines that the current over-provisioning amount is sufficient, the execution flow returns to step  710  where host  10  issues the Get_Overprovisioning_information API to drive  100  at the start of the next period. On the other hand, when host  10  determines that the current over-provisioning amount is not sufficient, host  10  at step  740  issues the Reconstruct API to drive  100 . As explained above, the Reconstruct API may be issued with an input parameter of 0, 1, or 2. 
     Upon receipt of the Reconstruct API, at step  745 , drive controller  120  returns an acknowledgement of receipt to host  10  (not shown) and determines if scanning of flash memory device  150  for bad blocks is needed according to the value of the input parameter included in the Reconstruct API. If the input parameter is 0, drive controller  120  proceeds to step  760  without scanning. If the input parameter is 1 or 2, drive controller  120  scans flash memory device  150  for bad blocks and updates bad block map  135  accordingly. If the input parameter is 1, drive controller  120  performs partial scanning for bad blocks and, if the input parameter is 2, drive controller  120  performs full scanning for bad blocks. During the partial or full scan for bad blocks, drive controller  120  updates bad block map  135  to include bad blocks that are discovered as a result of the scanning. The partial or full scan include a self-test comprising block erase tests, page program tests and/or page read tests. When an erase failure, a program failure, or an uncorrectable ECC failure occurs during the partial or full scan, a block in which the failure happens is determined as a bad block. 
     At step  760 , driver controller  120  computes a target logical capacity for flash memory device  150 . The target logical capacity is computed according to the formula: target logical capacity=raw physical capacity−predetermined over-provisioning amount−bad block capacity−system area amount. The bad block capacity is determined based on the information stored in bad block map  135  as described above in conjunction with step  715 . 
     If the predetermined over-provisioning amount is overridden by the second input parameter of the Reconstruct API, the target logical capacity is computed according to the formula: target logical capacity=raw physical capacity−overridden over-provisioning amount−bad block capacity−system area amount.  FIG. 9  illustrates graphically an example where the second input parameter of the Reconstruct API was given a value greater than the predetermined over-provisioning amount. 
     After the target logical capacity is computed at step  760 , driver controller  120  at step  770  carries out the reformatting of flash memory device  150  according to known techniques so that the resulting logical capacity after the reformatting is equal to the target logical capacity. It should be recognized that during this reformatting, user data stored in flash memory device  150  will be lost. In addition, host  10  will not be able to detect drive  100  and commands from host  10  will not be acknowledged. 
     Upon completion of the reformatting and as acknowledgement of successful completion, driver controller  120  at step  380  returns the target logical capacity to host  10 . Upon receipt of the target logical capacity at step  390 , host  10  recognizes that normal IO operation of drive  100  is resumed and resumes periodic polling for over-provisioning information at step  310 . 
     While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.