Operation method of open-channel storage device

Abstract

An open-channel storage device according to an embodiment of the present invention is configured to be controlled by a host including a bad block manager and includes a buffer memory and a non-volatile memory device. A method of operation of the open-channel storage device includes the steps of: performing a normal operation under the control of the host; detecting a sudden power-off immediately after a program fail for a first data block among a plurality of memory blocks included in the non-volatile memory device while performing the normal operation; dumping a plurality of user data stored in the buffer memory into a dump block among the plurality of memory blocks in response to the detected sudden power-off; detecting a power-on; and performing a data recovery operation for a plurality of user data stored in the dump block in response to the detected power-on.

Description

Technology Field

[0001] The present invention relates to a semiconductor memory, and more specifically, to a method of operating an open channel storage device. Background Technology

[0002] Semiconductor memory is classified into volatile memory devices, such as SRAM and DRAM, in which stored data is lost when the power supply is cut off, and non-volatile memory devices, such as flash memory devices, PRAM, MRAM, RRAM, and FRAM, which retain stored data even when the power supply is cut off.

[0003] Flash memory devices are widely used as mass storage media. However, due to the physical characteristics of flash memory devices, separate management means are required to manage them efficiently. In Solid State Drives (SSDs) based on flash memory devices, the Flash Translation Layer (FTL) is widely used as the aforementioned management means. In conventional SSDs, this Flash Translation Layer was performed by an internal controller; however, recently, host-level Flash Translation Layers configured to allow the host to control the overall operation of the SSD are being developed. The problem to be solved

[0004] The objective of the present invention is to provide a method of operation for an open-channel storage device having enhanced reliability. means of solving the problem

[0005] An open-channel storage device according to an embodiment of the present invention is configured to be controlled by a host including a bad block manager and includes a buffer memory and a non-volatile memory device. A method of operation of the open-channel storage device comprises: a step of performing a normal operation under the control of the host; a step of detecting a sudden power-off immediately after detecting a program failure for a first data block among a plurality of memory blocks included in the non-volatile memory device while performing the normal operation; a step of dumping a plurality of user data stored in the buffer memory into a dump block among the plurality of memory blocks in response to the detected sudden power-off; a step of detecting a power-on; and a step of performing a data recovery operation for the plurality of user data stored in the dump block in response to the detected power-on.

[0006] An open-channel storage device according to an embodiment of the present invention is configured to be controlled by a host including a bad block manager and includes a buffer memory and a non-volatile memory device. A method of operation of the open-channel storage device comprises: performing a normal operation under the control of the host; detecting a sudden power-off while performing the normal operation; dumping a plurality of user data stored in the buffer memory into a dump block among the plurality of memory blocks in response to the detected sudden power-off; detecting a power-on; performing a first data recovery operation for the plurality of user data from the dump block in response to the detected power-on; detecting a program failure for a first data block among the plurality of memory blocks included in the non-volatile memory device during the first data recovery operation; and performing a second data recovery operation different from the first data recovery operation in response to the detected program failure.

[0007] An open-channel storage device according to an embodiment of the present invention is configured to be controlled by a host including a bad block manager and includes a buffer memory and a non-volatile memory device. A method of operation of the open-channel storage device includes the steps of: performing a normal operation under the control of the host; detecting a normal power-off; performing a data flush operation in response to the detected normal power-off, wherein user data stored in the buffer memory is stored in a corresponding data block among a plurality of memory blocks included in the non-volatile memory device; detecting a program failure for a first data block among a plurality of memory blocks included in the non-volatile memory device during the data flush operation; transmitting error information to the host in response to the detected program failure; generating a first parity data based on first user data to be stored in the first data block, second user data corresponding to the first user data, and at least one dummy data; and storing the first parity data in a corresponding parity block among the plurality of memory blocks. Effects of the invention

[0008] According to an embodiment of the present invention, the reliability of user data in a storage device configured to be controlled by a host driving a host flash conversion layer can be improved. Accordingly, a method of operation of an open channel storage device having improved reliability is provided. Brief explanation of the drawing

[0009] FIG. 1 is a block diagram showing a computing system according to an embodiment of the present invention. Figure 2 is a diagram illustrating the software layer of the computing system of Figure 1 in an exemplary manner. Figure 3 is a block diagram exemplarily showing the storage controller of Figure 1. Figure 4 is a flowchart showing the operation of the story device of Figure 1. FIGS. 5a to 5d are drawings for explaining the operation according to the flowchart of FIG. 4. Figure 6 is a flowchart showing the operation for data recovery after a sudden power-off of the storage device of Figure 1. Figure 7 is a diagram for explaining the operation according to the flowchart of Figure 6. Figure 8 is a flowchart showing the operation of the storage device of Figure 1. FIGS. 9a to 9c are drawings for explaining the operation according to the flowchart of FIG. 8. FIGS. 10a to 10c are flowcharts showing the operation of the storage device of FIG. 1. FIGS. 11a to 11d are drawings for explaining operations according to the flowcharts of FIGS. 10a to 10c. FIG. 12 is a flowchart showing the operation of the storage device of FIG. 1. FIGS. 13a and FIGS. 13b are drawings for explaining the operation according to the flowchart of FIG. 12. FIG. 14 is a flowchart illustrating the operation between the host and the storage device of FIG. 1 in an exemplary manner. FIG. 15 is a block diagram exemplarily showing a server system to which a storage device according to an embodiment of the present invention is applied. Specific details for implementing the invention

[0010] In the following, embodiments of the present invention will be described clearly and in detail so that a person skilled in the art can easily practice the present invention.

[0011] FIG. 1 is a block diagram showing a computing system according to an embodiment of the present invention. Referring to FIG. 1, the computing system (100) may include a host (110) and a storage device (120). In an exemplary embodiment, the computing system (100) may include any one of various computing systems such as a personal computer, a laptop, a server, a workstation, a smartphone, a tablet, etc.

[0012] The host (110) may be configured to control the storage device (120). For example, the host (110) may store data in the storage device (120) or read data stored in the storage device (120).

[0013] The storage device (120) may be configured to operate under the control of the host (110). For example, the storage device (120) may include a storage controller (121), a buffer memory (122), and a non-volatile memory device (123).

[0014] A storage controller (121) may be configured to control a buffer memory (122) and a non-volatile memory device (123). The buffer memory (122) may be configured to store data received from a host (110), data stored in the non-volatile memory device (123), or various information required for the operation of the storage device (120). The non-volatile memory device (123) may be configured to store data or output stored data under the control of the storage controller (121). In an exemplary embodiment, the non-volatile memory device (123) may be a NAND flash memory device, but the scope of the invention is not limited thereto.

[0015] In an exemplary embodiment, a conventional storage device efficiently manages a non-volatile memory device using a separate management means (e.g., a Flash Translation Layer (FTL)). The Flash Translation Layer is configured to perform various operations for efficiently managing the non-volatile memory device, such as address translation, garbage collection, bad block management, and wear leveling. That is, the conventional storage device efficiently manages the non-volatile memory device by executing the aforementioned Flash Translation Layer itself.

[0016] However, according to an embodiment of the present invention, the flash conversion layer may be included in the host (110). In other words, the host (110) may include a host flash conversion layer (111). The host flash conversion layer (111) may be configured to perform management operations performed in a conventional storage device on behalf of the storage device.

[0017] In an exemplary embodiment, as the host flash translation layer (111) is executed by the host (111), the storage device (120) may be configured to receive a physical address from the host (110) indicating the location of the actual storage area of ​​the non-volatile memory device (123). That is, the storage controller (121) of the storage device (120) may receive the physical address from the host (110) and perform an operation on the location corresponding to the received physical address. That is, the storage device (120) may be an Open Channel Solid State Drive (OC-SSD). For convenience of explanation, the term "Storage Device" is used below, but the storage device may refer to an Open Channel SSD.

[0018] In an exemplary embodiment, the host flash conversion layer (111) may include a bad block manager (111a). The bad block manager (111a) may be configured to manage bad blocks among a plurality of memory blocks included in the non-volatile memory device (123). For example, if a bad block occurs among a plurality of memory blocks included in the non-volatile memory device (123), the bad block manager (111a) of the host flash conversion layer (111) may replace the bad block with a normal block.

[0019] In an exemplary embodiment, since the bad blocks of the non-volatile memory device (123) are managed by the bad block manager (111a) of the host flash conversion layer (111), under certain conditions, when a bad block of the non-volatile memory device (123) occurs, the data stored in the bad block or data to be stored may be lost.

[0020] According to an embodiment of the present invention, under certain conditions, the storage device (120) can guarantee data reliability for data stored or to be stored in a non-volatile memory device (123). A method for guaranteeing data reliability of the storage device (120) according to an embodiment of the present invention is described in more detail with reference to the drawings below.

[0021] FIG. 2 is a diagram illustrating the software layer of the computing system of FIG. 1 as an example. Referring to FIG. 1 and FIG. 2, the software layer of the host (110) may include a host flash conversion layer (111), an application (112), a file system (113), and a device driver (114).

[0022] Applications (112) may refer to various software running on the host (110). A file system (113) may serve to organize files or data used by applications. For example, a file system (113) may manage the storage space of a storage device (120) as logical addresses. In an exemplary embodiment, the file system (113) may have different forms depending on the operating system running on the host (110). For example, the file system (113) may include any one of various file systems such as FAT (File Allocation Table), FAT32, NTFS (NT File System), HFS (Hierarchical File System), JSF2 (Journaled File System2), XFS, ODS-5 (On-Disk Structure-5), UDF, ZFS, UFS (Unix File System), ext2, ext3, ext4, ReiserFS, Reiser4, ISO 9660, Gnome VFS, BFS, or WinFS.

[0023] The host flash translation layer (111) can provide an interface between a logical address managed by a file system (113) and a physical address of a non-volatile memory device (123) included in a storage device (120).

[0024] For example, the host flash translation layer (111) may perform address translation operations between logical addresses and physical addresses based on a map table (111b) containing information about the correspondence relationship between logical addresses and physical addresses. Alternatively, the host flash translation layer (111) may be configured to replace a bad block detected in the non-volatile memory device (123) with a normal block using a bad block manager (111a). Alternatively, the host flash translation layer (111) may be configured to perform scheduling of I / O to be provided to the storage device (120) using an I / O scheduler (111c). However, the scope of the present invention is not limited thereto, and the host flash translation layer (111) may perform various operations to efficiently manage the non-volatile memory device (123) of the storage device (120), such as garbage collection and wear leveling.

[0025] The device driver (114) may be configured to perform the operation of converting information from the host flash conversion layer (111) into information recognizable by the storage device (120).

[0026] In an exemplary embodiment, the above-described application (112), file system (113), host flash conversion layer (111), and device driver (114) may be implemented in software form, and these components may be driven by a processor (not shown) included in the host (110).

[0027] The storage controller (121) may be configured to store data in a non-volatile memory device (123) or to transmit data stored in the non-volatile memory device (123) to the host (110) based on information from the device driver (114) of the host (110).

[0028] In an exemplary embodiment, as previously described, since the logical address is converted to a physical address by the host flash conversion layer (111), the storage controller (121) will receive the physical address from the device driver (114) of the host (110). The storage controller (121) will perform a read / write / erase operation on the storage space corresponding to the received physical address (i.e., the physical storage space of the non-volatile memory device (123)).

[0029] FIG. 3 is a block diagram illustrating the storage controller of FIG. 1 as an example. Referring to FIG. 1 and FIG. 3, the storage controller (121) may include a core (121a), an error correction code engine (121b) (ECC Engine; Error Correction Code Engine), a buffer manager (121c), a RAID engine (121d), a host interface (121e), and a NAND interface (121f).

[0030] The core (121a) may be configured to control the general operations of the storage controller (121). The ECC engine (121b) may be configured to detect and correct errors in data stored in the non-volatile memory device (123). The buffer manager (121c) may be configured to manage or control the buffer memory (122).

[0031] The RAID engine (121d) may be configured to generate parity data for data to be stored in the non-volatile memory device (123). For example, multiple data may be stored in the non-volatile memory device (123). In this case, the multiple data may form a single stripe. The RAID engine (121d) may generate parity data for the single stripe by performing operations on the data included in the stripe.

[0032] As a more detailed example, if a stripe contains seven unit data, the RAID engine (121d) can generate one parity data having the same size as one unit data by performing an XOR operation on the seven unit data. In this case, a stripe may consist of seven unit data and one parity data. In an exemplary embodiment, the number of unit data and the number of parity data included in a stripe may be determined by the RAID policy of the RAID engine (121d).

[0033] In an exemplary embodiment, if any one of the seven unit data described above cannot be identified (i.e., if the error is not corrected by the ECC engine (121b)), the unidentified unit data can be recovered based on the remaining six data and one parity data.

[0034] In an exemplary embodiment, each of the multiple unit data included in a single stripe may be stored in a different memory block (or different bank), and the parity data corresponding to a single stripe may be stored in a parity block (or parity bank). In an exemplary embodiment, the memory block (or bank) where the unit data is stored and the parity block (or parity bank) where the parity data is stored may be varied according to a predetermined RAID policy. In an exemplary embodiment, the memory block (or bank) where the unit data is stored and the parity block (or parity bank) where the parity data is stored may be designated by a host flash conversion layer (111).

[0035] The storage controller (121) can communicate with the host (110) through the host interface (121e). In an exemplary embodiment, the host interface (121e) may include a Nonvolatile Memory Express (NVMe) interface, but the scope of the invention is not limited thereto. For example, the host interface (121e) may include at least one of various interfaces such as a Serial ATA (SATA) interface, a Peripheral Component Interconnect Express (PCIe) interface, a Serial Attached SCSI (SAS) interface, a Universal Flash Storage (UFS) interface, etc.

[0036] The storage controller (121) can communicate with the non-volatile memory device (123) through the NAND interface (121f).

[0037] FIG. 4 is a flowchart showing the operation of the storage device of FIG. 1. FIG. 5a to 5d are drawings for explaining the operation according to the flowchart of FIG. 4. Hereinafter, for convenience of explanation, components unnecessary for explaining the operation of the storage device (120) are omitted.

[0038] Additionally, for the sake of brevity of the drawings and convenience of explanation, it is assumed that the non-volatile memory device (123) includes 0 to 8 memory blocks (BLK0 to BLK8). It is assumed that each of the 0 to 6 memory blocks (BLK0 to BLK6) is a data block (D) that stores user data received from the host (110), and the 7th memory block (BLK7) is a parity block (P) configured to store parity data generated by the RAID engine (121d). That is, one stripe may include 7 user data and 1 parity data, and the 7 user data and 1 parity data included in one stripe may be stored in the 0 to 7 memory blocks (BLK0 to BLK7), respectively.

[0039] Additionally, the eighth memory block (BLK8) is assumed to be a dump block (DP) used to dump data stored in the buffer memory (122) under specific conditions (e.g., a sudden power-off situation). In an exemplary embodiment, the dump block (DP) may be a storage space not recognized by the host (110).

[0040] In an exemplary embodiment, each of the 0th to 7th memory blocks (BLK0 to BLK7) may be included in a different bank. Each of the memory cells included in each of the 0th to 7th memory blocks (BLK1 to BLK7) may be a multi-level cell configured to store n bits per cell (where n is an integer greater than or equal to 2). Each of the memory cells included in the 8th memory block (BLK8) may be a single-level cell configured to store 1 bit per cell or a multi-level cell configured to store m bits per cell (where m is an integer less than n). That is, the programming speed for the 8th memory block (BLK8) may be faster than the programming speed for each of the 0th to 7th memory blocks (BLK0 to BLK7).

[0041] The configurations described above are exemplary for clearly explaining embodiments of the present invention, and the scope of the present invention is not limited thereto.

[0042] Referring to FIGS. 1 and FIGS. 4, in step S110, the storage device (120) can perform normal operations. For example, the storage device (120) can perform a normal write operation as shown in FIG. 5a under the control of the host (110).

[0043] As a more detailed example, referring to FIG. 5a, the storage device (120) can receive 0 to 6 user data (D0 to D6) from the host (110). The received 0 to 6 user data (D0 to D6) can be stored in the buffer memory (122).

[0044] In an exemplary embodiment, although not illustrated in the drawings, when user data 0 to 6 (D0 to D6) is successfully stored in the buffer memory (122), the storage controller (121) of the storage device (120) may transmit a completion response to the host (110) indicating that user data 0 to 6 (D0 to D6) has been successfully received by the host (110). Based on the completion response, the host (110) may recognize that user data 0 to 6 (D0 to D6) has been successfully stored in the storage device (120).

[0045] The storage controller (121) can store the 0th to 6th user data (D0~D6) stored in the buffer memory (122) in the corresponding data blocks (D), namely the 0th to 6th data blocks (BLK0~BLK6). At this time, the RAID engine (121d) of the storage controller (121) can generate 0th parity data (P0) based on the 0th to 6th user data (D0~D6). The storage controller (121) can store the generated 0th parity data (P0) in the 7th memory block (BLK7), namely the parity block (P).

[0046] That is, the first stripe (STR1) may include 0 to 6 user data (D0~D6) and 0 parity data (P0), and the operation of storing each data included in the first stripe (STR1) in a corresponding memory block may be a normal write operation. In an exemplary embodiment, the normal write operation described above is performed by a host (110), and the physical location where each user data is stored may be specified by the host flash conversion layer (111) of the host (110).

[0047] As described above, since the first stripe (STR1) includes zero parity data (P0), even if any of the user data included in the first stripe (STR1) (e.g., D2) is not properly identified (e.g., even if the error is not corrected by the ECC engine (121b)), the second user data (D2) can be recovered based on the remaining user data (D0, D1, D3~D6) and zero parity data (P0).

[0048] Referring again to FIG. 4, in step S120, the storage device (120) may detect a power-off. For example, the storage device (120) may detect a power-off (PO) while performing normal operation as described with reference to FIG. 5a. In an exemplary embodiment, the power-off may include a normal power-off (NPO; normal power off) caused by a power-off signal received from the host (110), and a sudden power-off (SPO; sudden power off) caused by a sudden interruption of power.

[0049] For example, as illustrated in FIG. 5b, it is assumed that the buffer memory (122) stores the 0th to 3rd user data (D0 to D3) received from the host (110). In this case, since the host (110) recognizes that the 0th to 3rd user data (D0 to D3) has been written correctly, the reliability of the 0th to 3rd user data (D0 to D3) must be guaranteed.

[0050] Power-off (PO) may be detected after the 0th and 1st user data (D0, D1) are stored respectively in the 0th and 1st memory blocks (BLK0, BLK1), which are the corresponding data blocks (D). In this case, the 2nd and 3rd user data (D2, D3) will be retained in the buffer memory (122) since they have not yet been stored in the non-volatile memory device (123).

[0051] Referring again to FIG. 4, in step S130, the storage device (120) can determine whether the detected power-off is a normal power-off (NPO) or a sudden power-off (SPO). For example, if it is a normal power-off (NPO), the storage device (120) can receive information related to the normal power-off (NPO) from the host (110). On the other hand, if it is a sudden power-off (SPO), the storage device (120) can cut off the power voltage to the storage device (120) without receiving a separate signal from the host (110). The storage device (120) can determine whether the detected power-off is a normal power-off (NPO) or a sudden power-off (SPO) based on the power voltage and the signal from the host (110).

[0052] If the detected power-off is a normal power-off (NPO), the storage device (120) may perform the operations of steps S141 through S143. In step S141, the storage device (120) may perform a data flush operation. In step S142, the storage device (120) may generate parity data based on the stripe's data and dummy data. In step S143, the storage device (120) may write the generated parity data to the stripe's parity block. For convenience of explanation, the operations of the storage device (120) storing data stored in the buffer memory (122) into the corresponding data block (D), writing dummy data, and generating parity data when a normal power-off occurs are collectively referred to as a data flush operation.

[0053] For example, as illustrated in FIG. 5c, after the zero and first user data (D0, D1) are stored in the zero and first data blocks (BLK0, BLK1), which are corresponding data blocks (D), a normal power-off (NPO) may occur. In this case, the storage device (120) may write the second and third user data (D2, D3) stored in the buffer memory (122) to the second and third memory blocks (BLK2, BLK3), which are corresponding data blocks (D).

[0054] In an exemplary embodiment, according to the assumptions described above, the first stripe (STR1) contains 7 user data. On the other hand, during normal power-off (NPO), the first stripe (STR1) will contain 4 user data (D0, D1, D2, D3). In this case, dummy data (DM) may be written to each of the remaining data blocks (e.g., BLK4, BLK5, BLK6) corresponding to the first stripe (STR1). In an exemplary embodiment, the dummy data (DM) may be a predetermined data pattern or a random data pattern.

[0055] That is, after user data maintained in the buffer memory (122) is written into the corresponding data blocks, if a complete stripe is not formed, dummy data can be written into the remaining data blocks of the stripe.

[0056] Afterward, the RAID engine (121d) of the storage controller (121) can generate parity data (P0-m) based on user data (i.e., D0-D3) and dummy data (DM) contained in the first stripe (STR1). The generated parity data (P0-m) can be written to the seventh memory block (BLK7), which is the parity block (P).

[0057] As described above, when the storage device (120) detects a normal power-off (NPO) during normal operation, the storage device (120) may write user data maintained in the buffer memory (122) to corresponding data blocks and write dummy data to the remaining data blocks (i.e., the data blocks remaining to form the stripe). Subsequently, the storage device (120) may generate parity data based on the user data and dummy data included in the stripe and write the generated parity data to the parity block. Although the operation following the normal power-off described above has been explained for one stripe, the scope of the present invention is not limited thereto. For example, at the time of normal power-off, the storage device (120) may perform the operation described above for each of the plurality of stripes.

[0058] Referring again to FIG. 4, if the detected power-off is a sudden power-off (SPO), the storage device (120) can perform a data dump operation in step S150. For convenience of explanation, the operation of moving user data of the buffer memory (122) to a specific memory block (e.g., dump block (DP)) upon sudden power-off is collectively referred to as a data dump operation.

[0059] For example, as illustrated in FIG. 5d, a sudden power-off (SPO) may occur after the zero and first user data (D0, D1) are stored in corresponding data blocks (BLK0, BLK1), respectively. In this case, the storage device (120) may dump the second and third user data (D2, D3) maintained in the buffer memory (122) into the eighth memory block (BLK8), which is the dump block (DP). In other words, the storage device (120) may write the second and third user data (D2, D3) from the buffer memory (122) into the eighth memory block (BLK8).

[0060] In an exemplary embodiment, the speed at which the second and third user data (D2, D3) are written to the eighth memory block (BLK8) may be faster than the speed at which the second and third user data (D2, D3) are written to the corresponding data blocks. That is, the speed of the data dump operation performed in a sudden power off (SPO) may be faster than the speed of the data flush operation performed in a normal power off (NPO).

[0061] In an exemplary embodiment, during a dump operation upon sudden power-off (SPO), metadata (MD) for the second and third user data (D2, D3) may be dumped into the eighth memory block (BLK8). The metadata (MD) may include status information or location information for each of the second and third user data (D2, D3).

[0062] Although not illustrated in the drawings, metadata (MD) may be dumped into other memory blocks not illustrated in the drawings (e.g., firmware blocks, etc.), but the scope of the invention is not limited thereto.

[0063] As described above, the storage device (120) according to an embodiment of the present invention can write user data of the buffer memory (122) to corresponding data blocks and write dummy data to the remaining data blocks during normal power-off (NPO). Afterwards, parity data can be generated based on user data (or dummy data) in stripe units and the parity data can be written to the parity blocks. Thus, data reliability can be guaranteed during normal power-off.

[0064] In addition, the storage device (120) according to an embodiment of the present invention can quickly dump user data of the buffer memory (122) into a dump block upon sudden power-off (SPO). Data reliability can be ensured by the storage device (120) recovering data from the dump block (DP) upon power-on after sudden power-off (SPO). The operation of recovering data from the dump block (DP) upon power-on after sudden power-off (SPO) is described in detail with reference to FIGS. 6 and 7.

[0065] FIG. 6 is a flowchart showing the operation for data recovery after a sudden power-off of the storage device of FIG. 1. FIG. 7 is a diagram for explaining the operation according to the flowchart of FIG. 6.

[0066] Referring to FIGS. 1, FIGS. 6, and FIGS. 7, in step S210, the storage device (120) can be powered on. In step S220, the storage device (120) can determine whether the power-off prior to power-on was a sudden power-off (SPO).

[0067] For example, the storage device (120) may be normally powered off (NPO) or suddenly powered off (SPO), as described with reference to FIG. 4. The storage device (120) may determine whether the previous power-off was a normal power-off (NPO) or a sudden power-off (SPO) by referring to meta information (MD).

[0068] If the power-off prior to power-on is a normal power-off (NPO), the storage device (120) can perform normal operation in step S240. Since normal operation has been described with reference to the operation in step S110 of FIG. 4 and the operation in FIG. 5a, a detailed description thereof is omitted.

[0069] If the power-off prior to the power-on is a sudden power-off (SPO), the storage device (120) may perform a data recovery operation in step S230. For example, the storage device (120) may be powered on after the sudden power-off (SPO) described with reference to FIG. 4 and FIG. 5d. In this case, as shown in FIG. 7, some user data (e.g., D2, D3) may be stored in the eighth memory block (BLK8), which is the dump block (DP).

[0070] As previously explained, since the second and third user data (D2, D3) stored in the eighth memory block (BLK8) are user data temporarily stored in the eighth memory block (BLK8) by a sudden power-off (SPO), the second and third user data (D2, D3) must be written to the second and third memory blocks (BLK2, BLK3), which are the corresponding data blocks (D).

[0071] That is, the storage device (120) can move user data (e.g., D2, D3) stored in the dump block (DP) to the corresponding data blocks (e.g., BLK2, BLK3) by performing a data recovery operation upon power-on after a sudden power-off (SPO).

[0072] In an exemplary embodiment, the storage location of user data stored in a dump block (DP) can be determined based on metadata (MD). For example, during a data recovery operation of a storage device (120), the metadata (MD) is loaded into a buffer memory (MD), and the storage controller (121) can determine the storage location (i.e., BLK2, BLK3) of user data (e.g., D2, D3) stored in a dump block (DP) based on the metadata (MD). The storage controller (121) can write the user data of the dump block (DP) to the storage location determined based on the metadata (MD).

[0073] In an exemplary embodiment, after the data recovery operation is completed, the dump block (DP) may be processed as a free block for other operations (e.g., a dump operation during a subsequent sudden power off).

[0074] As described above, the storage device (120) according to an embodiment of the present invention can ensure the reliability of user data by performing a data flush operation (operations of steps S141 to S143 of FIG. 4) during a normal power-off (NPO). In addition, the storage device (120) can ensure the reliability of user data by performing a data dump operation (operation of step S150 of FIG. 4) during a sudden power-off (SPO) and performing a data recovery operation after the sudden power-off (SPO).

[0075] In an exemplary embodiment, a program failure (P / F) may occur for a specific memory block during a data flush operation after a normal power-off (NPO), a normal operation immediately before a sudden power-off (SPO), or a data recovery operation during a power-on after a sudden power-off (SPO). Since the conventional storage device executes the flash conversion layer itself, it can directly replace the memory block where the program failure (P / F) occurred (i.e., the bad block) with a normal block and perform subsequent operations normally.

[0076] On the other hand, since the storage device (120) (e.g., an open channel SSD) controlled by the host (110) configured to execute the host flash conversion layer (111) cannot perform its own bad block management, user data to be written to the bad blocks may be lost.

[0077] A storage device (120) according to an embodiment of the present invention can guarantee the reliability of data to be stored in a memory block that has a program failure (i.e., a bad block) when a program failure (P / F) occurs for a specific memory block during a data flush operation after a normal power-off (NPO), a normal operation immediately before a sudden power-off (SPO), or a data recovery operation during a power-on after a sudden power-off (SPO). With reference to the drawings below, a method for guaranteeing the reliability of user data of a storage device according to an embodiment of the present invention when a program failure (P / F) occurs for a specific block under specific conditions is described.

[0078] FIG. 8 is a flowchart illustrating the operation of the storage device of FIG. 1. FIGS. 9a through 9c are drawings for explaining the operation according to the flowchart of FIG. 8. With reference to FIG. 8 and FIGS. 9a through 9c, an embodiment in which a program fail (P / F) occurs during a data flush operation during a normal power-off (NPO) is described. For convenience of explanation, detailed descriptions of the previously described components are omitted. The memory block in which a program fail (P / F) occurs is referred to as a "bad block," and user data to be stored in the bad block is referred to as "program fail data (P / F data)." The embodiment described with reference to FIG. 8 and FIGS. 9a through 9c is illustrative for easily explaining the technical concept of the present invention, and the scope of the present invention is not limited thereto.

[0079] Referring to FIGS. 1 and FIGS. 8, in step S300, the storage device (120) can detect a normal power-off (NPO). Since the operation of step S300 has been described with reference to steps S120 and S130 of FIGS. 4, a detailed description thereof is omitted.

[0080] In step S301, the variable (k) is set to "1". In an exemplary embodiment, the variable (k) is merely for facilitating the repetitive operation of the storage device (120), and the scope of the invention is not limited accordingly.

[0081] In step S310, the storage device (120) can write the k-th user data from the buffer memory (122) to the corresponding data block. In step S320, the storage device (120) can determine whether a program fail (P / F) has occurred.

[0082] In the determination result of step S320, if a program failure (P / F) is detected, in step S330, the storage device (120) may report error information (ERI) to the host (110) and provide the k-th user data as input to the RAID engine (121d).

[0083] For example, as illustrated in FIG. 9a, after the zero and first user data (D0, D1) are respectively stored in the zero and first memory blocks (BLK0, BLK1), which are the corresponding data blocks (D), a normal power-off (NPO) may occur. In this case, the second and third user data (D2, D3) may be retained in the buffer memory (122).

[0084] In response to a normal power-off (NPO), the storage device (120) can write second user data (D2) from the buffer memory (122) to the second memory block (BLK2), which is the corresponding data block (D). At this time, a program fail (P / F) may occur during the program operation for the second memory block (BLK2).

[0085] In response to a program fail (P / F) for the second memory block (BLK2), the storage controller (121) may transmit error information (ERI) to the host (110). In an exemplary embodiment, the error information (ERI) may be provided as an Asynchronous Event Request Completion (AER Completion).

[0086] In an exemplary embodiment, the host (110) can recognize that a program fail (P / F) has occurred for the second memory block (BLK2) based on the received error information (ERI) (i.e., the second memory block (BLK2) is a bad block). The host (110) can replace the second memory block (BLK2), which is a bad block, with another normal block. In an exemplary embodiment, the replacement operation of the bad block can be performed by the bad block manager (111a) of the host flash conversion layer (111) described with reference to FIGS. 1 and 2.

[0087] The storage device (120) can provide the second user data (D2) (i.e., P / F data) to be stored in the second memory block (BLK2) where a program fail (P / F) occurred, as input to the RAID engine (121d) without the intervention of the host (110).

[0088] Referring again to FIG. 8, at step S340, it can be determined whether the variable (k) is at its maximum value. In an exemplary embodiment, the variable (k) being at its maximum value indicates that all user data maintained in the buffer memory (122) has been written to the corresponding data block (whereby bad blocks may be excluded).

[0089] If the variable (k) is not at its maximum, in step S341, the variable (k) is increased by "1", and the storage device (120) can perform the operation of step S310. If the variable (k) is at its maximum, in step S350, the storage device (120) can determine whether there are any remaining data blocks in the stripe.

[0090] If there are remaining data blocks, in step S360, the storage device (120) may write dummy data (DM) to the remaining data blocks. If there are no remaining data blocks or after the operation of step S360, in step S370, the storage device (120) may generate parity data and write the generated parity data to the corresponding parity blocks.

[0091] For example, as illustrated in FIG. 9b, third user data (D3) from buffer memory (122) can be written to the third memory block (BLK3). The written third user data (D3) can be provided as input to the RAID engine (121d).

[0092] Similar to what was previously described, if the first stripe (STR1) contains 7 user data and 1 parity data, 7 user data are required to generate parity data. On the other hand, at the point when the writing of the third user data (D3) is completed, the data input to the RAID engine (121d) consists of a total of 4 user data (D0~D3), so additional data may be required to generate parity. In this case, the storage device (120) can write dummy data (DM) to each of the remaining data blocks (e.g., BLK4, BLK5, BLK6).

[0093] Accordingly, the RAID engine (121d) can generate parity data (P0-m) based on the 0th to 3rd user data (D0~D3) and three additional dummy data (DM). The generated parity data (P0-m) can be written to the 7th memory block (BLK7), which is the parity block (P).

[0094] In an exemplary embodiment, as illustrated in FIG. 9b, a program fail (P / F) may occur in the second memory block (BLK2), so that the second user data (D2) is not written to the second memory block (BLK2). However, the second user data (D2) that was not written to the second memory block (BLK2) can be restored based on the parity data (P0-m) stored in the seventh memory block (BLK7), which is the parity block (P), and the user data (D0, D1, D3~D6) stored in other data blocks (BLK0, BLK1, BLK3~BLK6).

[0095] Therefore, in the data flush operation during normal power-off (NPO), even if a program fail (P / F) occurs for a specific block, the host (110) can subsequently use the corresponding parity data to restore the data to be stored in the data block (i.e., the bad block) where the program fail (P / F) occurred.

[0096] In an exemplary embodiment, a data flush operation for a plurality of stripes may be performed during a normal power-off (NPO). For example, as illustrated in FIG. 9c, a normal power-off (NPO) may occur after the zero and first user data (D0, D1) are stored in the zero and first memory blocks (BLK0, BLK1), which are corresponding data blocks (D). At this time, it is assumed that the buffer memory (122) retains the second to tenth user data (D2~D10).

[0097] In this case, the storage device (120) can write the second to sixth user data (D2~D6) to the corresponding data blocks (BLK2~BLK6) respectively in response to a normal power-off (NPO). At this time, a program fail (P / F) may occur for the second memory block (BLK2). In this case, the storage device (120) can generate parity data (P0-m) based on the operation method described with reference to FIG. 9b and write the generated parity data (P0-m) to the seventh memory block (BLK7), which is the corresponding parity block (P). That is, by performing the operation described above, the storage device (120) can form a first stripe (STR1) containing the zero to sixth user data (D0~D6) and the zero parity data (P0-m).

[0098] Subsequently, the storage device (120) can write the remaining user data (D7~D10) to the corresponding data blocks (BLK0~BLK3), respectively. At this time, since the second memory block (BLK2) is a bad block, the ninth user data (D9) may not be written normally to the second memory block (BLK2). (i.e., there is a high probability that a program fail (P / F) will occur again.) Therefore, in order to improve data reliability and operation speed, the storage device (120) may skip (SKP) the program operation for the second memory block (BLK2) that has failed (P / F). However, the ninth user data (D9) to be written to the second memory block (BLK2) will be provided as an input to the RAID engine (121d).

[0099] Subsequently, the storage device (120) writes the 10th user data (D10) into the 3rd memory block (BLK3), which is the corresponding data block (D), writes dummy data (DM) into the remaining data blocks (BLK4, BLK5, BLK6), and can generate the 1st parity data (P1-m) based on the 7th to 10th user data (D7~D10) and the dummy data (DM) (e.g., three dummy data). The generated 1st parity data (P1-m) can be stored in the 7th memory block (BLK7), which is the parity block (P). That is, by performing the above-described operation, the storage device (120) can form a 2nd stripe (STR2) containing the 7th to 10th user data (D7~D10) and the 1st parity data (P1-m).

[0100] As described above, the storage device (120) according to an embodiment of the present invention may not write user data corresponding to the memory block that has a program failure (P / F) when a program failure (P / F) occurs for a specific memory block during a data flush operation at normal power-off (NPO). Instead, it may generate parity data based on user data corresponding to the memory block that has a program failure (P / F) and user data or dummy data included in the corresponding stripe, and write the generated parity data to the parity block. Accordingly, the reliability of user data that was not written normally due to a program failure (P / F) can be guaranteed.

[0101] FIGS. 10a to 10c are flowcharts showing the operation of the storage device of FIG. 1. FIGS. 11a to 11d are drawings for explaining the operations according to the flowcharts of FIGS. 10a to 10c.

[0102] With reference to FIGS. 10a to 10c and FIGS. 11a to 11d, embodiments are described in a situation where a sudden power-off (SPO) occurs immediately after a program fail (P / F) occurs for a specific memory block. However, this is intended to facilitate the explanation of embodiments of the present invention and the scope of the present invention is not limited thereto.

[0103] First, referring to FIG. 1 and FIG. 10a, in step S410, the storage device (120) can detect a program failure (P / F) during normal operation. In step S420, the storage device (120) can report error information (ERI) to the host (110) in response to the detected program failure (P / F).

[0104] For example, as illustrated in FIG. 11a, the storage device (120) may write first user data (D1) stored in the buffer memory (122) to the first memory block (BLK1), which is the data block (D). At this time, a program fail (P / F) may occur in the first memory block (BLK1). In response to the program fail (P / F) of the first memory block (BLK1), the storage controller (121) may transmit error information (ERI) to the host (110). In an exemplary embodiment, the error information (ERI) may be provided through AER completion.

[0105] Subsequently, at step S430, the storage device (120) can detect a sudden power-off (SPO) immediately after a program fail (P / F). At step S440, the storage device (120) can perform a data dump operation in response to the detected sudden power-off (SPO).

[0106] For example, as illustrated in FIG. 11b, a sudden power-off (SPO) may occur immediately after a program fail (P / F) for the first memory block (BLK1). In this case, the buffer memory (122) will retain the first to third user data (D1 to D3). This is because the first user data (D1) was not properly written to the first memory block (BLK1), which is the corresponding data block (D), due to the program fail (P / F) of the first memory block (BLK1).

[0107] Similar to what is described with reference to FIG. 5d, the storage device (120) may dump user data (i.e., D1, D2, D3) maintained in the buffer memory (122) into an eighth memory block (BLK8) which is a dump block (DP). In an exemplary embodiment, metadata (MD) for the first to third user data (D1 to D3) may be dumped into the eighth memory block (BLK8) which is a dump block (DP). Although not illustrated in the drawings, metadata (MD) for the first to third user data (D1 to D3) may be dumped into another separate memory block.

[0108] In an exemplary embodiment, if a sudden power-off occurs after a sufficient amount of time has elapsed since a program failure (P / F), the first user data (D1) may not be retained in the buffer memory (122). This is because, before the sudden power-off (SPO) occurs, if the host (110) recognizes that a program failure (P / F) has occurred in the first memory block (BLK1) in response to error information (ERI) and the host (110) reads the first user data (D1), the first user data (D1) may be released from the buffer memory (122). In this case, since the host (110) recognizes the first user data (D1) normally, a separate dump operation for the first user data (D1) may not be required.

[0109] Subsequently, at step S450, the storage device (120) can be powered on. At step S460, the storage device (120) can perform a data recovery operation in a program fail (P / F).

[0110] For example, as described with reference to FIGS. 6 and 7, in a data recovery operation without a program fail (P / F), the storage device (120) can migrate user data stored in the eighth memory block (BLK8), which is a dump block (DP), to corresponding data blocks.

[0111] On the other hand, if a sudden power-off (SPO) occurs immediately after a program fail (P / F), a separate data recovery operation may be performed for the data to be stored in the memory block that failed the program (P / F).

[0112] For example, referring to FIG. 1, FIG. 10a, and FIG. 10b, when the storage device (120) is powered on after a sudden power-off (SPO) immediately after a program fail (P / F), the storage device (120) can perform data recovery operations in the program fail (P / F) by performing the operations of steps S461A through S461D.

[0113] In step S461A, the storage device (120) can migrate user data from the dump block to the corresponding data block. At this time, user data to be stored in the data block that is a program fail (P / F) (i.e., P / F data) may be excluded.

[0114] After this, the storage device (120) may perform the operations of steps S461B through S461D. Since the operations of steps S461B through S461D are similar to the operations of steps S350 through S370 of FIG. 8, a detailed description thereof is omitted.

[0115] For example, as illustrated in FIG. 11c, when the storage device (120) is powered on, the eighth memory block (BLK8), which is a dump block (DP), may include first to third user data (D1 to D3) and metadata (MD).

[0116] In this case, the storage device (120) can determine the location where the first to third user data (D1 to D3) are to be stored (i.e., the physical location of the memory block) and the memory block that is a program fail (P / F) based on the metadata (MD).

[0117] In the embodiment of FIG. 11c, since a program fail (P / F) occurs in the first memory block (BLK1), the program operation for the first memory block (BLK1) is omitted, and the first user data (D1), which is the P / F data, is provided as an input to the RAID engine (121d).

[0118] The storage device (120) can write the second and third user data (D2, D3) stored in the eighth memory block (BLK8), which is the dump block (DP), to the corresponding data blocks (D), which are the second and third memory blocks (BLK2, BLK3), respectively. Subsequently, similar to the description above, the storage device (120) can write dummy data (DM) to each of the remaining data blocks (e.g., BLK4 to BLK6). Subsequently, similar to the description above, the RAID engine (121d) of the storage controller (121) can generate parity data (P0-m) based on the zero to third user data (D0 to D3) and dummy data (DM) (i.e., three dummy data) contained in the first stripe (STR1). The generated parity data (P0-m) can be written to the seventh memory block (BLK7), which is the parity block (P).

[0119] As described above, if a sudden power-off (SPO) occurs immediately after a program fail (P / F) for a specific memory block, the storage device (120) according to an embodiment of the present invention may dump user data remaining in the buffer memory (122) into a dump block (DP). Upon subsequent power-on, the storage device (120) writes user data from the dump block (DP) to corresponding data blocks, and may generate parity data based on the P / F data from the dump block (DP) (i.e., user data to be written to the memory block that is the program fail (P / F)) and the data written to the data blocks (or dummy data). Accordingly, the P / F data can be restored normally using the corresponding parity data.

[0120] In an exemplary embodiment, for example, with reference to FIG. 1, FIG. 10a, and FIG. 10c, when the storage device (120) is powered on after a sudden power-off (SPO) immediately after a program fail (P / F), the storage device (120) can perform data recovery operations in the program fail (P / F) by performing the operations of steps S462A through S462D.

[0121] In step S462A, the storage device (120) can write user data from the dump block (DP) to the corresponding data block (D). In step S462B, the storage device (120) can determine whether a program fail (P / F) has occurred for a specific memory block.

[0122] When a program fail (P / F) occurs for a specific memory block, in step S462C, the storage device (120) can load user data (i.e., P / F data) to be written to the memory block that is the program fail (P / F) into the buffer memory (122) and report the associated error information (ERI') to the host.

[0123] In step S462D, the storage device (120) can release an area of ​​the buffer memory (122) where P / F data is stored in response to a confirm command from the host (110).

[0124] For example, as illustrated in FIG. 11d, the eighth memory block (BLK8), which is the dump block (DP) of the power-on storage device (120), may include first to third user data (D1 to D3) and metadata (MD).

[0125] The storage device (120) can write the first to third user data (D1~D3) from the eighth memory block (BLK8), which is the dump block (DP), to the corresponding data blocks (D), which are the first to third memory blocks (BLK1~BLK3). At this time, since the first memory block (BLK1) is a bad block, a program fail (P / F) will occur for the first memory block (BLK1). In this case, the first user data (D1) will be P / F data.

[0126] The storage device (120) can respond to a program fail (P / F) for the first memory block (BLK1), load the first user data (D1), which is the P / F data, into the buffer memory (122), and transmit the associated error information (ERI') to the host (110).

[0127] Although not illustrated in the drawing, the host (110) may, in response to error information (ERI'), recognize that a program failure (P / F) has occurred for the first memory block (BLK1) and read the first user data (D1) loaded into the buffer memory (122). Alternatively, the host (110) may, in response to error information (ERI'), perform a bad block replacement operation.

[0128] In an exemplary embodiment, the storage device (120) can load the first user data (D1) into the buffer memory (122) without a program operation for the first memory block (BLK1) based on metadata (MD). For example, the metadata (MD) may include information indicating that a program failure (P / F) for the first memory block (BLK1) occurred immediately before a sudden power-off (SPO). Based on the metadata (MD), the storage device (120) can recognize that a program failure (P / F) for the first memory block (BLK1) occurred prior to the sudden power-off (SPO). Accordingly, the storage device (120) can load the first user data (D1) into the buffer memory (122) without a program operation for the first user data (D1). Subsequently, the storage device (120) can transmit error information (ERI') to the host (110).

[0129] As described above, a storage device (120) according to an embodiment of the present invention can load user data (i.e., P / F data) to be stored in a memory block that is a program fail (P / F) into a buffer memory (122) and transmit related error information (ERI') to a host (110). The host (110) can read the P / F data loaded into the buffer memory (122) in response to the error information (ERI'). Therefore, even if a sudden power-off occurs immediately after a program fail (P / F) for a specific memory block, the reliability of the user data remaining in the buffer memory (122) is guaranteed.

[0130] FIG. 12 is a flowchart showing the operation of the storage device of FIG. 1. FIG. 13a and FIG. 13b are drawings for explaining the operation according to the flowchart of FIG. 12. Referring to FIG. 1 and FIG. 12, the storage device (120) can perform steps S510 and S520. Since the operations of steps S510 and S520 are similar to the operations of steps S120, S130, and S150 of FIG. 4, a detailed description thereof is omitted.

[0131] Subsequently, the storage device (120) may perform steps S530 and S540. Since the operations of steps S530 and S540 are similar to the operations of steps S210 through S230 of FIG. 6, a detailed description thereof is omitted.

[0132] In step S550, the storage device (120) may detect a program failure (P / F) during the data recovery operation. For example, the storage device (120) may perform the data recovery operation by migrating user data stored in the dump block (DP) to corresponding data blocks. At this time, a program failure (P / F) may occur for a specific data block.

[0133] In step S560, the storage device (120) may perform a data recovery operation in response to a detected program failure (P / F). For example, the storage device (120) may operate based on the operation methods described with reference to FIGS. 10a to 10c and FIGS. 11a to 11d.

[0134] That is, the storage device (120) can generate parity data for the corresponding stripe by providing the P / F data as input to the RAID engine without writing user data (i.e., P / F data) to be stored in the memory block (i.e., bad block) which is a program fail (P / F) to the bad block. Alternatively, the storage device (120) can load the P / F data to be stored in the bad block into the buffer memory (122) and provide the relevant error information (ERI') to the host (110).

[0135] As a more detailed example, in the embodiment illustrated in FIGS. 13a and 13b, it is assumed that the zero and first user data (D0, D1) are respectively stored in the zero and first memory blocks (BLK0, BLK1), which are corresponding data blocks (D), and subsequently, a sudden power-off (SPO) occurs, and accordingly, the second and third user data (D2, D3) and metadata (MD) are dumped into the eighth memory block (BLK8), which is a dump block (DP). Additionally, it is assumed that upon power-on following the sudden power-off (SPO), a program fail (P / F) occurs for the second memory block (BLK2). However, these conditions and assumptions are illustrative for clearly explaining the embodiments of the present invention and the scope of the present invention is not limited thereto.

[0136] Referring to FIGS. 1, FIGS. 12, and FIGS. 13a, upon power-on following a sudden power-off (SPO), the storage device (120) can write second and third user data (D2, D3) from the eighth memory block (BLK8), which is a dump block (DP), to the second and third memory blocks (BLK2, BLK3), which are corresponding data blocks (D), respectively. At this time, a program fail (P / F) may occur in the second memory block (BLK2). In this case, the storage device (120) can provide the second user data (D2) to be written to the second memory block (BLK2) as an input to the RAID engine (121d) in response to the program fail (P / F) of the second memory block (BLK2), and transmit the associated error information (ERI) to the host (110).

[0137] In an exemplary embodiment, writing dummy data (DM) to each of the remaining data blocks (e.g., BLK4 to BLK6), the RAID engine (121d) generating parity data (P0-m) based on user data and dummy data included in one stripe, and storing the parity data (P0-m) in the seventh memory block, which is the parity block (P), are similar to those previously described, so a detailed description thereof is omitted.

[0138] Alternatively, referring to FIGS. 1, 12, and 13b, or FIGS. 1, 12, and 13a, the storage device (120) may write second and third user data (D2, D3) from the eighth memory block (BLK8), which is a dump block (DP), to the second and third memory blocks (BLK2, BLK3), which are corresponding data blocks (D), respectively. At this time, a program fail (P / F) may occur in the second memory block (BLK2). In this case, the storage device (120) may, in response to the program fail (P / F) of the second memory block (BLK2), load the second user data (D2) to be written to the second memory block (BLK2) into the buffer memory (122) and transmit the associated error information (ERI) to the host (110). Since the subsequent host (110) reads the second user data (D2) loaded into the buffer memory (122) in response to the error information (ERI), a detailed description thereof is omitted.

[0139] That is, as described above, the storage device (120) can perform a data recovery operation on user data stored in a dump block (DP) upon power-on after a sudden power-off (SPO). If a program fail (P / F) occurs for a specific memory block during the data recovery operation, the storage device (120) can guarantee the reliability of the P / F data by generating parity data based on the remaining user data including the P / F data, or by loading the P / F data into a buffer memory (122) and providing the relevant error information (ERI) to the host (110).

[0140] FIG. 14 is a flowchart illustrating the operation between the host and the storage device of FIG. 1. For convenience of explanation, specific descriptions according to the previously described embodiments are omitted. However, the scope of the present invention is not limited thereto, and each operation according to the flowchart of FIG. 14 may be implemented as at least one or a combination of at least two of the previously described embodiments.

[0141] Referring to FIGS. 1 and FIGS. 14, in step S1010, the host (110) and the storage device (120) can perform normal operations. For example, the host (110) and the storage device (120) can perform normal operations as described with reference to FIG. 5a.

[0142] In step S1001, the storage device (120) can transmit error information (ERI) to the host (110). For example, the storage device (120) can perform normal operation under the control of the host (110). During normal operation, a program failure (P / F) for a specific memory block can be detected. In this case, as described with reference to FIG. 1, the storage device (120) does not have a bad block management function, so it can provide error information (ERI) regarding the program failure (P / F) to the host (110).

[0143] In an exemplary embodiment, error information (ERI) may be provided as a completion of an asynchronous event request (AER). For example, the host (110) may transmit an AER to the storage device (120) during an initialization operation with the storage device (120). The AER may be used for the storage device (120) to provide specific information to the host (110) independently of the host's control. When a specific event (e.g., a program fail (P / F)) occurs in the storage device (120), the relevant information (i.e., error information (ERI)) may be provided to the host (110) as a response to the completion of the aforementioned AER.

[0144] In step S1002, the host (110) can perform bad block management based on error information (ERI). For example, as described with reference to FIG. 1, the host flash conversion layer (111) of the host (110) can manage bad blocks contained in the non-volatile memory device (123) of the storage device (120). That is, the host (110) can replace the bad blocks with normal blocks and update the associated map table in response to the received error information (ERI).

[0145] In step S1020, the storage device (120) may be powered off. For example, as previously described, the storage device (120) may detect a normal power-off (NPO) or a sudden power-off (SPO) by detecting information about a normal power-off (NPO) or a drop in power voltage from the host (110).

[0146] In step S1030, the storage device (120) may perform a data backup operation. In an exemplary embodiment, the operation in step S1030 may include a data flush operation after a normal power-off (NPO) or a data dump operation after a sudden power-off (SPO) as described with reference to FIGS. 1 to 13b. That is, the storage device (120) may operate according to any one of the embodiments described with reference to FIGS. 1 to 13b depending on the type of detected power-off or whether / when a program fail (P / F) occurs.

[0147] In an exemplary embodiment, if the detected power-off is a normal power-off (NPO) and a program fail (P / F) occurs during the operation of step S1030, the storage device (120) may transmit error information (ERI) to the host (110) in step S1003. Although not illustrated in the drawings, the host (110) may perform bad block management in response to the error information (ERI).

[0148] Subsequently, in step S1110, the host (110) and the storage device (120) are powered on and can perform an initialization operation. In an exemplary embodiment, during the initialization operation, the previously described AER may be provided from the host (110) to the storage device (120).

[0149] In step S1120, the storage device (120) may perform a data recovery operation. For example, the storage device (120) may be configured to perform any one of the embodiments described with reference to FIGS. 1 to FIGS. 13b or a combination thereof, depending on the type of previous power-off (i.e., whether NPO or SPO) and whether / when a program fail (P / F) occurred.

[0150] In an exemplary embodiment, if a program failure (P / F) occurs during the operation of step S1030, the storage device (120) may transmit error information (ERI) to the host (110). Although not illustrated in the drawing, the host (110) may perform bad block management in response to the error information (ERI).

[0151] In an exemplary embodiment, the operations for transmitting error information (ERI) in steps S1001, S1003, and S1004 are shown as dashed lines in FIG. 14 because they are performed selectively according to the operation method or embodiment, or because the timing of when the operations of each step are performed is not specified. The operations for transmitting error information (ERI) in steps S1001, S1003, and S1004 may be performed selectively according to the previously described embodiments, and since the timing of when the error information (ERI) is transmitted according to each embodiment has been described in each embodiment, a detailed description thereof is omitted.

[0152] In step S1130, the host (110) may send a read request to the storage device (120) in response to error information (ERI). In an exemplary embodiment, the read request may be a read request to read user data (i.e., P / F data) to be stored in a memory block that is a program fail (P / F) (i.e., a bad block). Alternatively, the read request may be a read request to read data of a stripe containing P / F data (where the P / F data may be excluded) and parity data.

[0153] In step S1140, the storage device (120) can determine whether data corresponding to the received read request exists in the buffer memory (122) (i.e., determine whether it is a cache hit). For example, if the storage device (120) operates according to an embodiment in which P / F data is loaded into the buffer memory (122), the data corresponding to the read request (i.e., P / F data) will exist in the buffer memory (122).

[0154] In this case (i.e., in the case of a cache hit), at step S1170, the storage device (120) can transfer the corresponding user data (i.e., P / F data) from the buffer memory (122) to the host (110).

[0155] On the other hand, if the storage device (120) operates according to an embodiment in which it provides P / F data as input to the RAID engine (121d) to generate parity data, the data corresponding to the read request (i.e., P / F data) may not exist in the buffer memory (122).

[0156] In this case (i.e., in the case of a cache miss), at step S1150, the storage device (120) can transmit parity data and the remaining data corresponding to the stripe containing P / F data to the host (110).

[0157] In step S1160, the host (110) can restore P / F data based on the data and parity data received through step S1150.

[0158] Subsequently, at step S1180, the host (110) may send a confirmation command to the storage device (120). In an exemplary embodiment, the storage device (120) may release the buffer memory (122) in which the P / F data is stored in response to the confirmation command.

[0159] In an exemplary embodiment, the confirmation command may include a Get Log Page command, a manufacturer command, or a combination of various commands.

[0160] FIG. 15 is a block diagram illustrating an exemplary server system to which a storage device according to an embodiment of the present invention is applied. Referring to FIG. 15, the server system (1000) may include a host system (1100) and a plurality of open channel SSDs (OC-SSDs). In an exemplary embodiment, the server system (1000) may include a server, a workstation, or a data center, etc.

[0161] The host system (1100) may include a plurality of host FTLs (1111–111n), a storage manager (112), and a plurality of device drivers (1131–113m). Each of the plurality of host FTLs (1111–111n) may be configured to manage the physical storage space of each of the plurality of open channel SSDs (OC-SSDs). For example, each of the plurality of host FTLs (1111–111n) may include a map table, a bad block manager, an I / O scheduler, a wear leveling manager, a garbage collection manager, etc. The storage manager (1120) may be configured to manage the network of the plurality of open channel SSDs (OC-SSDs). Each of the plurality of device drivers (1131–113m) may be configured to perform data conversion for communication with the corresponding open channel SSD (OC-SSD).

[0162] Each of the multiple open channel SSDs (OC-SSD) may be directly connected to the host system (1100) or connected to the host system (1100) through a network fabric. Each of the multiple open channel SSDs (OC-SSD) may operate under the control of the host system (1100). For example, each of the multiple open channel SSDs (OC-SSD) may receive a physical address pointing to a direct location of storage space from the host system (1100) and perform an operation on the storage space corresponding to the received physical address.

[0163] In an exemplary embodiment, each of the plurality of open channel SSDs (OC-SSDs) may operate according to any one of the embodiments described with reference to FIGS. 1 to 14 or a combination thereof. That is, when a program fail (P / F) occurs under a specific condition (e.g., power-off), each of the plurality of open channel SSDs (OC-SSDs) may operate according to any one of the embodiments described with reference to FIGS. 1 to 14 or a combination thereof, thereby ensuring the reliability of user data.

[0164] The above description describes specific embodiments for implementing the present invention. The present invention will include not only the embodiments described above, but also embodiments that can be simply modified or easily modified. Furthermore, the present invention will include technologies that can be easily modified and implemented using the embodiments. Accordingly, the scope of the present invention should not be limited to the embodiments described above, but should be defined by the claims set forth below as well as equivalents to the claims of this invention.

Claims

Claim 1 A method of operation of an open-channel storage device comprising a buffer memory and a non-volatile memory device, configured to be controlled by a host including a bad block manager, comprising: a step of performing a normal operation according to the control of the host; a step of detecting a sudden power-off immediately after a program fail for a first data block among a plurality of memory blocks included in the non-volatile memory device while performing the normal operation; a step of dumping a plurality of user data stored in the buffer memory into a dump block among the plurality of memory blocks in response to the detected sudden power-off; a step of detecting a power-on; and a step of performing a data recovery operation for the plurality of user data stored in the dump block in response to the detected power-on, wherein the step of performing the data recovery operation comprises: a step of loading a first user data to be stored in the first data block among the plurality of user data dumped into the dump block into the buffer memory; a step of transmitting error information to the host; and a step of receiving a read request for the first user data from the host after transmitting the error information to the host. A method of operation comprising: transmitting the first user data loaded into the buffer memory to the host in response to the above read request; receiving a completion command from the host; and releasing the buffer memory loaded with the first user data in response to the completion command. Claim 2 A method of operation according to claim 1, wherein the memory cells included in the dump block are configured to store n-bits per cell (where n is a positive integer), and the memory cells included in the first data block are configured to store m-bits per cell (where m is a positive integer greater than n). Claim 3 In claim 1, the method of operation in which the error information is transmitted to the host through Asynchronous Event Request Completion (AER Completion). Claim 4 In claim 1, the step of performing the normal operation comprises: receiving the plurality of user data from the host; storing the received plurality of user data in the buffer memory; storing the plurality of user data from the buffer memory in corresponding data blocks among the plurality of memory blocks; generating at least one parity data based on the plurality of user data; and storing the at least one parity data in a corresponding parity block among the plurality of memory blocks. Claim 5 A method of operation in which the normal operation is performed based on a physical address received from the host in claim 1. Claim 6 In claim 1, the first data block is replaced by another normal block among the plurality of memory blocks by the bad block manager of the host. Claim 7 A method of operation of an open-channel storage device comprising a buffer memory and a non-volatile memory device, configured to be controlled by a host including a bad block manager, comprising: a step of performing a normal operation according to the control of the host; a step of detecting a sudden power-off immediately after a program fail for a first data block among a plurality of memory blocks included in the non-volatile memory device while performing the normal operation; a step of dumping a plurality of user data stored in the buffer memory into a dump block among the plurality of memory blocks in response to the detected sudden power-off; a step of detecting a power-on; and a step of performing a data recovery operation for the plurality of user data stored in the dump block in response to the detected power-on, wherein the step of performing the data recovery operation comprises: a step of storing the remaining user data among the plurality of user data dumped into the dump block, excluding the first user data to be stored in the first data block, in corresponding data blocks among the plurality of memory blocks; and a step of generating parity data based on at least one second user data corresponding to the first user data among the remaining user data, the first user data, and at least one dummy data. A method of operation comprising the step of storing the parity data in a corresponding parity block among the plurality of memory blocks. Claim 8 In claim 7, the operation method wherein the first user data and the at least one second user data are included in the same stripe. Claim 9 In claim 7, the method of operation further comprises: receiving a read request for the first user data from the host; recovering the first user data based on the second user data, the at least one dummy data, and the parity data in response to the read request; and transmitting the recovered first user data to the host. Claim 10 In claim 7, the method of operation further comprises: transmitting error information regarding the first user data to the host; receiving a read request for the second user data and the parity data from the host; and transmitting at least one second user data and the parity data to the host in response to the read request. Claim 11 In claim 10, the operation method in which the first user data is recovered by the host based on the at least one second user data and the parity data. Claim 12 A method of operation of an open-channel storage device comprising a buffer memory and a non-volatile memory device, configured to be controlled by a host including a bad block manager, comprising: a step of performing a normal operation according to the control of said host; a step of detecting a sudden power-off while performing the normal operation; a step of dumping a plurality of user data stored in said buffer memory into a dump block among said plurality of memory blocks in response to said detected sudden power-off; a step of detecting a power-on; a step of performing a first data recovery operation for said plurality of user data from said dump block in response to said detected power-on; and a step of detecting a program failure for a first data block among said plurality of memory blocks included in said non-volatile memory device during said first data recovery operation. A method of operation comprising the step of performing a second data recovery operation different from the first data recovery operation in response to the detected program failure, wherein the first data recovery operation includes the operation of storing the plurality of user data from the dump block into corresponding data blocks among the plurality of memory blocks, and the second data recovery operation includes: loading the first user data to be stored in the first data block into the buffer memory, transmitting error information regarding the first user data to the host, and after transmitting the error information, receiving a read request for the first user data from the host, in response to the read request, transmitting the first user data loaded into the buffer memory to the host, and releasing the buffer memory in which the first user data is stored in response to a confirmation command from the host. Claim 13 In claim 12, the second data recovery operation comprises: generating parity data based on first user data to be stored in the first data block, at least one second user data corresponding to the first user data, and at least one dummy data, and storing the generated parity data in a corresponding parity block among the plurality of memory blocks.

Images