Memory system

Abstract

To provide a memory system that can effectively use resources.SOLUTION: A controller sets a first size, which is a size of a data management unit by a host, to a maximum writable size among a plurality of superblocks. Upon receipt of one or more write commands from the host, where the one or more write commands designate a first management unit having the first size, the controller writes, to a first superblock, data having a second size, which is a writable size in the first superblock, among data belonging to the first management unit, and writes, to a second superblock, data having a third size, which is a difference between the first size and the second size, among the data belonging to the first management unit.SELECTED DRAWING: Figure 11

Description

[Technical Field]

[0001] FIELD OF THE INVENTION Embodiments of the present invention relate to techniques for controlling non-volatile memory. [Background technology]

[0002] In recent years, memory systems equipped with nonvolatile memories have become widespread. One such memory system is a solid-state drive (SSD) equipped with a NAND flash memory.

[0003] An SSD may use a superblock (also called a logical block or block group), which is composed of multiple physical blocks, as a unit for data erasure. The total size of data that can be written to a superblock varies depending on whether each of the multiple physical blocks that make up the superblock is a bad block. In other words, the sizes of the multiple superblocks within an SSD may differ. By using superblocks, an SSD can improve performance by operating the multiple physical blocks that make up a superblock in parallel. However, if the host issues write commands to write multiple types of data, different types of data will be mixed within a single superblock.

[0004] In response to this, it is possible to set logical partitions for each type of data and assign a write destination superblock to each of the set partitions. Here, the logical partitions assigned to the superblocks have a fixed size determined between the host and the SSD.

[0005] There is a need for efficient allocation of superblocks, each of which may have a different size, to logical partitions of fixed size. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] US Patent Application Publication No. 2024 / 0012580 [Patent Document 2] US Patent Application Publication No. 2024 / 0028231 [Patent Document 3] US Patent Application Publication No. 2023 / 0019966 Summary of the Invention [Problem to be solved by the invention]

[0007] An embodiment of the present invention provides a memory system that can efficiently utilize resources. [Means for solving the problem]

[0008] According to an embodiment, a memory system is connectable to a host. The memory system includes a nonvolatile memory and a controller. The nonvolatile memory includes a plurality of physical blocks, each of which is a unit of data erase operations. The controller is electrically connected to the nonvolatile memory. The controller manages a plurality of superblocks, each of which includes one or more physical blocks from the plurality of physical blocks and includes at least a first superblock and a second superblock. The controller sets a first size, which is the size of a data management unit used by the host, to the largest data size writable to each of the plurality of superblocks. The controller notifies the host of the set first size. In response to receiving one or more write commands from the host specifying a first management unit having the first size, the controller writes data belonging to the first management unit of a second size, which is the data size writable to the first superblock, to the first superblock. The controller writes data belonging to the first management unit of a third size, which is the difference between the first size and the second size, to the second superblock. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a block diagram showing an example of the configuration of an information processing system including a memory system according to an embodiment. [Figure 2] FIG. 2 is a diagram showing an example of the configuration of a memory chip included in the memory system according to the embodiment. [Figure 3] FIG. 2 is a diagram showing an example of a superblock managed in the memory system according to the embodiment. [Figure 4] FIG. 2 is a diagram showing an example of the functional configuration of a CPU included in the memory system according to the embodiment. [Figure 5] 1 is a diagram for explaining data writing in accordance with Flexible Data Placement (FDP), which is executed in an information processing system including a memory system according to an embodiment. [Figure 6] 10A and 10B are diagrams showing examples of the writable sizes of each of a plurality of superblocks managed in the memory system according to the embodiment; [Figure 7] FIG. 10 is a diagram for explaining the relationship between superblocks managed in a memory system according to a first comparative example and RU sizes. [Figure 8] FIG. 10 is a diagram for explaining the relationship between superblocks managed in a memory system according to a second comparative example and RU sizes. [Figure 9] FIG. 2 is a diagram showing a superblock to which data is written in the memory system according to the embodiment. [Figure 10] FIG. 10 is a sequence diagram illustrating management of RU sizes in the memory system according to the embodiment. [Figure 11] FIG. 2 is a first diagram illustrating a write process in the memory system according to the embodiment. [Figure 12] FIG. 2 is a second diagram illustrating a write process in the memory system according to the embodiment. [Figure 13] FIG. 10 is a diagram showing an example of a refresh process executed in a memory system according to a third comparative example. [Figure 14] FIG. 10 is a diagram showing an example of a refresh process executed in the memory system according to the embodiment. [Figure 15] FIG. 2 is a diagram showing a first example of garbage collection processing executed in the memory system according to the embodiment. [Figure 16] FIG. 10 is a diagram showing a second example of garbage collection processing executed in the memory system according to the embodiment. [Figure 17] 10 is a flowchart showing the procedure of a write process executed in the memory system according to the embodiment. [Figure 18] 10 is a flowchart showing the procedure of a refresh process executed in the memory system according to the embodiment. [Figure 19] 10 is a flowchart showing the procedure of a garbage collection process executed in the memory system according to the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, an embodiment will be described with reference to the drawings. The configuration of an information processing system including a memory system according to an embodiment will be described below. Fig. 1 is a block diagram showing an example of the configuration of an information processing system 1 including a memory system 3 according to an embodiment.

[0011] The information processing system 1 includes a host (host device) 2 and a memory system 3.

[0012] The host 2 is an information processing device configured to control the memory system 3. Examples of the host 2 include a personal computer, a server computer, a mobile terminal, or an in-vehicle device.

[0013] The memory system 3 is a semiconductor storage device configured to write data to and read data from a nonvolatile memory. The memory system 3 may be realized as, for example, a solid-state drive (SSD). An example in which the memory system 3 is realized as an SSD will be described below. Hereinafter, the memory system 3 will be referred to as SSD 3.

[0014] Communication between the host 2 and the SSD 3 is performed via a bus 7. The bus 7 is a transmission path that connects the host 2 and the SSD 3. The bus 7 is, for example, a PCI express TM (PCIe TM ) bus. The PCIe bus is a full duplex transmission path. The full duplex transmission path includes both a transmission path for transmitting data and input / output (I / O) commands from the host 2 to the SSD 3, and a transmission path for transmitting data and responses from the SSD 3 to the host 2. An I / O command is a command for writing data to a nonvolatile memory or reading data from a nonvolatile memory. An I / O command is, for example, a write command or a read command.

[0015] The write command is a command that requests writing of data to the SSD 3. The write command includes information indicating the start logical address, the size of the data (write data) associated with the write command, and a data pointer. The start logical address is the first logical address of the logical address range corresponding to the write data. For example, a Logical Block Address (LBA) is used for this logical address. The size of the write data is represented by, for example, the number of LBAs (number of sectors) included in the logical address range corresponding to the write data. The data pointer is an address that indicates the storage location in the memory 22 of the host 2 where the write data is stored.

[0016] The read command is a command requesting that data be read from the SSD 3. The read command includes information indicating the start logical address, the size of the data to be read (read data), and a data pointer. The start logical address is the first logical address of the logical address range corresponding to the read data. The size of the read data is represented by the number of LBAs (number of sectors) included in the logical address range corresponding to the read data. The data pointer is an address indicating the storage location in the memory 22 of the host 2 to which the read data should be transferred.

[0017] The logical interface standard for connecting the host 2 and the SSD 3 is, for example, NVM express. TM (NVMe TM ) standard is used. In the NVMe standard interface, communication between the host 2 and the SSD 3 is performed using a pair of queues including at least one submission queue (SQ) and a completion queue (CQ) associated with the at least one submission queue (SQ). This pair of queues is called a submission queue / completion queue pair (SQ / CQ pair).

[0018] When the host 2 issues an I / O command to the SSD 3, it stores the I / O command to be issued in a submission queue (SQ). The SSD 3 then receives the I / O command by accessing the submission queue (SQ) and fetching the I / O command. When processing related to the received command is completed, the SSD 3 stores a completion response corresponding to the processed command in a completion queue (CQ). The completion response includes, for example, information indicating that processing related to the corresponding command has been completed. The host 2 recognizes that processing related to the issued command has been completed by processing the completion response stored in the completion queue (CQ).

[0019] If the host 2 and SSD 3 support Flexible Data Placement (FDP), the host 2 may issue a write command that includes information specifying the reclaim unit (RU) to which data is to be written.

[0020] An RU is a unit of data management by the host 2. An RU may also be referred to as a logical division. Data belonging to one RU is associated with multiple LBAs. An RU is used by the host 2 as a unit that allows data to be erased / recycled without interfering with other RUs. The size of an RU is notified to the host 2 by the SSD 3. For example, one superblock may be allocated to each RU in the SSD 3. The superblock is used as a unit of data erasure processing in the SSD 3. Details of superblocks will be described later.

[0021] A write command compliant with the FDP includes a Reclaim Unit Handle (RUH) as information for specifying the RU to which the data is to be written. The SSD3 can manage multiple RUs by associating them with one RUH. However, of the multiple RUs associated with one RUH, only one RU is in an open state. The open state is a state in which data can be written. Therefore, by specifying one RUH, one open RU corresponding to this RUH is specified as the RU to which the data is to be written. The SSD3, which has received the write command, determines the RU to which the write data is to be written, based on the RUH included in the received write command. A specific example of the write data write process compliant with the FDP, which is executed in the SSD3, will be described later.

[0022] In other words, in a data write process that complies with the FDP, the write destination superblock is specified based on the RUH included in the write command. Therefore, by using different RUHs depending on the type of data to be written to the SSD 3, the host 2 can separate the write destination superblocks for each type of data. This allows the SSD 3 to perform data erasure processing on only the superblocks that store that specific type of data when that data is no longer needed. The SSD 3 can then reuse the superblocks that have undergone data erasure processing to write new data.

[0023] Next, an example of the configuration of the host 2 will be described.

[0024] The host 2 includes a processor 21 and a memory 22. The processor 21 and the memory 22 are connected via a bus 20.

[0025] The processor 21 is, for example, a Central Processing Unit (CPU). The processor 21 executes software (host software) loaded into the memory 22. The host software is loaded into the memory 22 from the SSD 3 or another storage device connected to the host 2. The host software includes an operating system, a file system, a device driver, an application program, and the like. The processor 21 may also execute multiple applications.

[0026] The memory 22 is, for example, a volatile memory. The memory 22 is also referred to as a main memory, a system memory, or a host memory. The memory 22 is, for example, a random access memory such as a dynamic random access memory (DRAM). A part of the storage area of ​​the memory 22 is used as a data buffer. The data buffer stores write data to be written to the SSD 3 by the host 2 or read data transferred from the SSD 3.

[0027] Next, an example of the configuration of the SSD 3 will be described.

[0028] The SSD 3 includes a controller 4 , a NAND flash memory 5 , and a DRAM 6 .

[0029] The controller 4 is a memory controller that controls the NAND flash memory 5. The controller 4 may be realized by a circuit such as a System-on-a-chip (SoC). The controller 4 is electrically connected to the NAND flash memory 5.

[0030] The NAND flash memory 5 is a non-volatile semiconductor memory. The NAND flash memory 5 includes multiple NAND chips. The NAND chips are also referred to as memory chips, flash dies, or memory dies. Each NAND chip includes a memory cell array having multiple memory cells arranged in a matrix. The NAND flash memory 5 may be a two-dimensional flash memory or a three-dimensional flash memory.

[0031] The DRAM 6 is a volatile memory. The storage area of ​​the DRAM 6 is used, for example, to store information for managing the SSD 3. A part of the storage area of ​​the DRAM 6 may be used to temporarily store data to be written to the NAND flash memory 5 or data read from the NAND flash memory 5.

[0032] The controller 4 includes a host interface circuit (I / F) 41, a CPU 42, a static RAM (SRAM) 43, a direct memory access controller (DMAC) 44, an ECC circuit 45, a NAND interface circuit (I / F) 46, and a DRAM interface circuit (I / F) 47. The host I / F 41, the CPU 42, the SRAM 43, the DMAC 44, the ECC circuit 45, the NAND I / F 46, and the DRAM I / F 47 are connected to each other via an internal bus 40.

[0033] The host I / F 41 is an interface circuit configured to communicate with the host 2. The host I / F 41 is, for example, a PCIe controller. The host I / F 41 receives various commands from the host 2. These commands are, for example, NVMe commands defined in the NVMe standard. The commands received from the host 2 include, for example, the I / O commands (write commands and read commands) described above, as well as a trim command for invalidating data.

[0034] The CPU 42 is a processor. The CPU 42 controls the host I / F 41, the SRAM 43, the DMAC 44, the ECC circuit 45, the NAND I / F 46, and the DRAM I / F 47. In response to startup of the SSD 3, the CPU 42 loads a control program (firmware) from the NAND flash memory 5 or a ROM (not shown) into the SRAM 43. The CPU 42 then executes the loaded firmware to perform various processes. This firmware may be loaded into the DRAM 6 instead of the SRAM 43. The CPU 42 can execute command processing and the like to process various commands from the host 2. The operation of the CPU 42 is controlled by the firmware described above. Some or all of the command processing may be executed by dedicated hardware within the controller 4.

[0035] The SRAM 43 is a volatile memory. A part of the storage area of ​​the SRAM 43 is used as a working area for the CPU 42. Another part of the storage area of ​​the SRAM 43 can be used as a data buffer for temporarily storing data to be written to the NAND flash memory 5 or data read from the NAND flash memory 5.

[0036] The DMAC 44 is a circuit that executes direct memory access (DMA) and transfers data between the memory 22 of the host 2 and the SRAM 43 or the DRAM 6.

[0037] The ECC circuit 45 executes encoding or decoding. The ECC circuit 45 executes encoding when data is written to the NAND flash memory 5. In encoding, the ECC circuit 45 adds a redundant code (parity) to the data to be written to the NAND flash memory 5. The redundant code is, for example, an error correction code (ECC). In addition, when data is read from the NAND flash memory 5, the ECC circuit 45 executes decoding. In decoding, the ECC circuit 45 executes error correction on the data read from the NAND flash memory 5. When executing error correction, the ECC circuit 45 uses the ECC added to this data.

[0038] The NAND I / F 46 is a circuit that controls the NAND flash memory 5 under the control of the CPU 42. The NAND I / F 46 is electrically connected to a plurality of NAND chips included in the NAND flash memory 5.

[0039] Multiple NAND chips can operate independently. Therefore, the NAND chips function as a unit capable of operating in parallel. The NAND I / F 46 includes, for example, NAND controllers (NANDCs) 461-1, 461-2, ..., 461-8. The NANDCs 461-1, 461-2, ..., 461-8 are connected to channels ch1, ch2, ..., ch8, respectively. Each of the NANDCs 461-1, 461-2, ..., 461-8 is connected to one or more NAND chips via the corresponding channel. FIG. 1 illustrates a case in which four NAND chips are connected to each of channels ch1, ch2, ..., ch8. In this case, the NANDC 461-1 is connected to NAND chips #1, #9, #17, and #25 via channel ch1. The NANDC 461-2 is connected to NAND chips #2, #10, #18, and #26 via channel ch2. Similarly, NANDC 461-8 is connected to NAND chips #8, #16, #24, and #32 via channel ch8. NAND chips #1, #2, ..., #8 are treated as bank BNK1 by the controller 4. NAND chips #9, #10, ..., #16 are treated as bank BNK2 by the controller 4. NAND chips #17, #18, ..., #24 are treated as bank BNK3 by the controller 4. NAND chips #25, #26, ..., #32 are treated as bank BNK4 by the controller 4. A bank is a unit in which multiple NAND chips operate in parallel through interleaving.

[0040] In the configuration of the NAND flash memory 5 shown in FIG. 1, the controller 4 can access the NAND chips #1 to #32 in parallel using eight channels and bank interleaving. Therefore, the controller 4 can write or read data to a maximum of 32 NAND chips in parallel. In this case, the number of parallel accesses is 32. Note that each of the NAND chips #1 to #32 may have a multi-plane configuration having multiple planes. For example, if each of the NAND chips #1 to #32 includes two planes, the controller 4 can write or read data to a maximum of 64 planes in parallel. In this case, the number of parallel accesses is 64.

[0041] The DRAM I / F 47 is a circuit configured to control the DRAM 6 under the control of the CPU 42 .

[0042] A portion of the storage area of ​​the DRAM 6 can be used to store information for managing the SSD 3. For example, the DRAM 6 includes an L2P table 61, a block management table 62, an active block list 63, a free block list 64, and an overflow management table 65.

[0043] The L2P table 61 is a table that manages the correspondence between logical addresses and physical addresses. A physical address is an address that indicates a storage location in the NAND flash memory 5. A physical address is also called a Physical Block Address (PBA) or a Memory Block Address (MBA). The L2P table 61 manages the correspondence between LBAs and PBAs, for example, on a sector-by-sector basis.

[0044] The block management table 62 is a table for managing physical blocks and superblocks in the SSD 3. The block management table 62 includes, for example, information on bad blocks among the physical blocks in the SSD 3, and information on the multiple physical blocks that make up each superblock. A bad block is a block from which data cannot be read or written normally. A bad block may also be called a bad block.

[0045] During the manufacturing process of NAND chips #1 to #32, defective blocks may occur in each NAND chip. Controller 4 manages the defective blocks contained in each NAND chip (or each plane within each NAND chip) using block management table 62. Block management table 62 stores defect information indicating the defective blocks contained in each NAND chip (or each plane).

[0046] The bad blocks managed by the block management table 62 may include only bad blocks (primary bad blocks) that occur during the manufacturing process of the NAND chips #1 to #32, or may include both primary bad blocks and bad blocks (grown bad blocks) that occur after the start of use of the SSD 3. Information indicating each bad block that occurs during the manufacturing process of the NAND chips #1 to #32 may be loaded into the block management table 62 from the NAND flash memory 5.

[0047] The active block list 63 is a list of superblocks that contain at least valid data. Valid data is data stored in a memory location indicated by a physical address associated with a logical address. For example, data stored in a memory location indicated by a PBA referenced by the L2P table 61 is valid data. Valid data is also data that may be read by the host 2. The superblocks managed in the active block list 63 are superblocks that are assigned as write destination blocks or superblocks for which writing has been completed, and that store one or more valid data. The superblocks managed in the active block list 63 may be referred to as active blocks, for example.

[0048] The free block list 64 is a list of superblocks that store only invalid data. Invalid data is data stored in a storage location indicated by a physical address that is not associated with a logical address. For example, data stored in a storage location indicated by a PBA that is not referenced by the L2P table 61 is invalid data. Invalid data is also data that can no longer be read by the host 2. The superblocks managed in the free block list 64 are superblocks to which new data can be written by executing a data erasure process. The superblocks managed in the free block list 64 are called, for example, free blocks. A free block is a superblock that can be used again to write data.

[0049] The overflow management table 65 is a table that manages, for each superblock, the physical address range that indicates the storage area where overflow data is stored. Overflow data is data that belongs to an RU to which a write-destination superblock is assigned, but that could not be written to the write-destination superblock. For example, if the size of the writable storage area in the write-destination superblock is less than the total size of the data belonging to the RU, the data equivalent to the difference between these sizes can become overflow data. The overflow management table 65 manages the correspondence between superblocks and physical address ranges that indicate the storage area where data that overflows from this superblock is stored.

[0050] Next, an example of the internal configuration of a NAND chip will be described. Fig. 2 is a diagram showing an example of the configuration of a NAND chip included in the SSD 3 according to the embodiment. In Fig. 2, NAND chip #1 will be described as an example, but the other NAND chips #2 to #32 also have a similar configuration to NAND chip #1.

[0051] NAND chip #1 includes two planes (plane PLN1 and plane PLN2) and two peripheral circuits (peripheral circuit 50-1 and peripheral circuit 50-2) corresponding to the two planes, respectively.

[0052] Each of the planes PLN1 and PLN2 includes a memory cell array. The memory cell array of each of the planes PLN1 and PLN2 includes physical blocks BLK1 to BLKx. Each of the physical blocks is a unit of a data erase operation. Each of the physical blocks BLK1 to BLKx is also referred to as a flash block or a memory block. Each of the physical blocks BLK1 to BLKx includes pages P1 to Py. Each of the pages P1 to Py is a unit of a data write operation and a data read operation. Each of the pages P1 to Py includes, for example, a plurality of memory cells connected to the same word line.

[0053] Each of the peripheral circuits 50-1 and 50-2 is a circuit that controls the memory cell array of the corresponding plane. The peripheral circuit 50-1 corresponds to the plane PLN1. The peripheral circuit 50-2 corresponds to the plane PLN2. Each of the peripheral circuits 50-1 and 50-2 includes, for example, a row decoder, a column decoder, a sense amplifier, and a page buffer. In response to receiving an address and a command from the NAND interface 46, each of the peripheral circuits 50-1 and 50-2 performs a data write operation, a data read operation, or a data erase operation on the memory cell array of the corresponding plane.

[0054] Next, a superblock will be described. FIG. 3 is a block diagram showing an example of the configuration of a superblock in an SSD 3 according to an embodiment. The SSD 3 configures a superblock, which is a collection of physical blocks. The collection of physical blocks that configure a superblock is, for example, a collection of physical blocks selected one by one from planes that can operate in parallel. A superblock is also called a logical block or a block group. Here, a case will be described in which the number of channels is 8, the number of banks is 4, and the number of planes is 2.

[0055] One superblock includes a total of 64 physical blocks, one selected from each plane of 32 NAND chips corresponding to a configuration of 8 channels x 4 banks. If each of NAND chips #1 to #32 has a configuration of only one plane, one superblock includes a total of 32 physical blocks, one selected from each of NAND chips #1 to #32.

[0056] 3 shows an example of one superblock SB5 including 64 physical blocks. Here, the superblock SB5 is made up of physical blocks BLK5 of the planes PLN1 and PLN2 of the NAND chips #1 to #32.

[0057] The controller 4 can execute data erasure processing in units of superblocks. Hereinafter, it is assumed that data erasure processing is executed in units of superblocks in SSD 3. That is, the controller 4 executes data erasure processing on superblock SB5 when all data in superblock SB5 is invalid data. In the data erasure processing on superblock SB5, a data erasure operation is executed on each of the physical blocks 5 included in superblock SB5.

[0058] The controller 4 can also execute a data write operation in parallel to multiple physical blocks 5 that make up a superblock SB5. In this data write operation, the controller 4 writes data to a superpage, which is a collection of pages selected one by one from each of the multiple physical blocks 5. At this time, the controller 4 may write parity, which is used for error correction when data is read, to at least one of the multiple pages that make up the superpage. A superpage is also called a logical page.

[0059] Next, a description will be given of an example of the functional configuration of the CPU 42. Fig. 4 is a block diagram showing an example of the functional configuration of the CPU 42 included in the SSD 3 according to the embodiment.

[0060] By executing firmware, the CPU 42 functions as a write control circuit 421, a refresh control circuit 422, and a garbage collection (GC) control circuit 423. Some or all of these functions may be realized by dedicated hardware within the controller 4.

[0061] The write control circuit 421 controls the process of writing data to the NAND flash memory 5. In response to receiving a write command from the host 2, the write control circuit 421 executes the process of writing data.

[0062] If the received write command does not include an RUH, the write control circuit 421 executes normal data write processing. That is, if the write command received from the host 2 does not specify a management unit (RU) to which the data is to be written, the write control circuit 421 executes normal write processing. The write control circuit 421 acquires data associated with the received write command from the host 2 and writes the data to the NAND flash memory 5. The write control circuit 421 updates the L2P table 61 so that the LBA specified by the write command corresponds to the physical address indicating the storage location in the NAND flash memory 5 where the data has been written. The write control circuit 421 then transmits a completion response corresponding to the processed write command to the host 2.

[0063] On the other hand, if the write command includes an RUH, the write control circuit 421 executes data write processing in accordance with Flexible Data Placement (FDP). That is, if the write command received from the host 2 specifies a management unit (RU) of the write destination, the write control circuit 421 executes data write processing in accordance with FDP. At this time, the write control circuit 421 identifies the write destination superblock based on the RUH specified by the write command. The write control circuit 421 acquires data associated with the received write command from the host 2 and writes the data to the identified superblock in the NAND flash memory 5. The write control circuit 421 updates the L2P table 61 so that the LBA specified by the write command corresponds to the physical address indicating the storage location in the NAND flash memory 5 where the data has been written. The write control circuit 421 then transmits a completion response corresponding to the processed write command to the host 2.

[0064] The refresh control circuit 422 is a circuit that controls refresh processing in the SSD 3. The refresh processing is a process of reading and writing data for which a certain amount of time has passed since the data was written to the NAND flash memory 5. At this time, the refresh control circuit 422 may perform error correction processing on the read data. When data stored in a certain superblock is determined to be data to be refreshed, the refresh control circuit 422 reads the data from the superblock and writes the read data to another superblock (or the same superblock). The refresh control circuit 422 then updates the L2P table 61 so that the LBA corresponding to the data moved by the refresh processing corresponds to the physical address indicating the storage location of the superblock to which the new data has been written.

[0065] The GC control circuit 423 is a circuit that controls garbage collection (GC) processing in the SSD 3. GC processing is processing for reducing the number of superblocks in the SSD 3 that contain a mixture of valid data and invalid data and increasing the number of free blocks. For example, the GC control circuit 423 executes GC processing when the remaining number of free blocks falls below a threshold. In GC processing, the GC control circuit 423 selects a superblock as a garbage collection (GC) source superblock. For example, the GC control circuit 423 prioritizes selecting a superblock with a low proportion of valid data as a GC source superblock from among multiple active blocks in the SSD 3. The GC control circuit 423 then selects a garbage collection (GC) destination superblock to which valid data stored in the GC source superblock should be written. For example, the GC control circuit 423 selects a free block managed in the free block list 64 as a GC destination superblock. Alternatively, the GC control circuit 423 may select a write destination superblock in a normal data write process (i.e., a write process corresponding to a write command that does not include an RUH) as a GC destination superblock.

[0066] Next, a specific example of data writing processing conforming to the FDP will be described. Fig. 5 is a diagram illustrating data writing conforming to the FDP, which is executed in the information processing system 1 including the SSD 3 according to the embodiment.

[0067] Before explaining the data write process compliant with FDP, we will explain the data write process when the host or SSD does not support FDP. In this case, the host issues a write command that does not specify an RUH. Hereinafter, a write command that does not specify an RUH will be referred to as a normal write command. In this case, the host issues a normal write command based on each of multiple applications running in parallel within the host. The host issues a normal write command to the SSD regardless of which of the multiple applications issued the write command.

[0068] When an SSD receives a normal write command, it writes the data associated with the received write command to a destination superblock for normal data write processing.

[0069] As a result, if the host or SSD does not support FDP, data based on multiple applications will be mixed in the write destination superblock. When data related to a specific application is no longer needed in a superblock to which data has been written using this write method, the host sends a trim command to the SSD specifying the data related to that specific application. Upon receiving the trim command, the SSD invalidates the data related to that application in the SSD. As a result, valid data and invalid data may be stored in a single superblock.

[0070] Returning to the explanation of Figure 5, it is assumed in Figure 5 that host 2 and SSD 3 support FDP.

[0071] Assume that host 2 is running four applications (applications 1 to 4) in parallel. For example, host 2 assigns one RUH to each application. Application 1 is assigned RUH1. Application 2 is assigned RUH2. Application 3 is assigned RUH3. Application 4 is assigned RUH4.

[0072] When writing data compliant with FDP, host 2 issues a write command including information specifying an RUH corresponding to each application. Specifically, when writing data based on application 1, host 2 issues a write command specifying RUH1. When writing data based on application 2, host 2 issues a write command specifying RUH2. When writing data based on application 3, host 2 issues a write command specifying RUH3. When writing data based on application 4, host 2 issues a write command specifying RUH4.

[0073] Here, it is assumed that SSD3 includes one endurance group and one reclaim group.

[0074] An endurance group is a storage area contained in one domain. An endurance group contains one or more reclaim groups.

[0075] A reclaim group is a collection that includes one or more reclaim units (RUs).

[0076] If there is one endurance group and one reclaim group in SSD3, one write destination RU is determined by specifying one RUH. In other words, SSD3 has as many writable RUs as there are RUHs. Also, if there are two or more endurance groups, one endurance group is specified by a namespace identifier (ID). If there are two or more reclaim groups, one reclaim group within the endurance group is specified by the reclaim group identifier (ID). Then, one RU within the reclaim group is specified by the RUH.

[0077] The SSD3 allocates a write destination superblock (SB) for each RUH. One write destination SB corresponds to one write destination RU. In other words, the SSD3 allocates one superblock for one RU. For example, the write destination SB allocated to RUH1 stores data associated with a write command that specifies RUH1. The write destination SB allocated to RUH2 stores data associated with a write command that specifies RUH2. The write destination SB allocated to RUH3 stores data associated with a write command that specifies RUH3. The write destination SB allocated to RUH4 stores data associated with a write command that specifies RUH4.

[0078] When the write destination SB runs out of free storage space and new data can no longer be written, the controller 4 releases the allocation of that superblock to the write destination SB. The controller 4 then selects an arbitrary superblock from the free block list 64. The controller 4 executes a data erase process on the selected superblock and allocates this superblock as the new write destination SB.

[0079] If one superblock is assigned to one RU and the superblock does not contain any bad blocks, the free storage area of ​​the superblock will match the free storage area of ​​the RU. In other words, when the free storage area of ​​the superblock runs out, the free storage area of ​​the RU will also run out. Therefore, a superblock assigned to a new write destination SB is associated with the new write destination RU.

[0080] In this way, the controller 4 determines the write destination SB for the data associated with the write command based on the RUH included in the received write command. That is, each piece of data associated with a write command specifying a different RUH is written to a different write destination SB. This allows the host 2 to avoid storing data related to different applications in a single superblock. Here, a case has been described in which a different RUH is assigned to each application. However, if multiple users use the host 2 or SSD 3, a different RUH may be assigned to each user. Furthermore, if multiple hosts 2 use the SSD 3, a different RUH may be assigned to each of the multiple hosts 2. In either case, the host 2 and SSD 3 can avoid storing different types of data in a single superblock by using multiple RUHs.

[0081] In this case, when data related to a specific application is no longer needed, the host 2 sends a trim command to the SSD 3 specifying the data related to that specific application. For example, the host 2 sends a trim command to the SSD 3 to invalidate data in a specific RU. Upon receiving the trim command, the SSD 3 invalidates the data belonging to the RU specified by the trim command. As a result, the superblock allocated to the no longer needed RU becomes a free block that stores only invalid data without GC processing. This improves the write amplification factor (WAF) of the SSD 3. The WAF is the ratio of the total size of data written to the NAND flash memory 5 to the size of data written to the NAND flash memory 5 based on a write command received from the host 2.

[0082] Next, the writable size of a superblock will be described. Fig. 6 is a diagram showing an example of the writable size of each of a plurality of superblocks managed in the SSD 3 according to the embodiment.

[0083] Although FIG. 5 illustrates a case in which a superblock does not contain a bad block, each of the multiple superblocks in SSD 3 may contain a bad block. Data cannot be written to a storage area corresponding to a bad block among the multiple physical blocks that make up a superblock. Hereinafter, a storage area corresponding to a bad block will be referred to as a defective area. On the other hand, a storage area to which data can be written will be referred to as a writable area.

[0084] The writable sizes of the three types of superblocks will be described with reference to superblocks SB1, SB2, and SB3 shown in FIG.

[0085] The superblock SB1 in FIG. 6 is a superblock that does not contain any defective blocks. In other words, the superblock SB1 is a superblock that does not contain any defective areas. Each physical block in the superblock SB1 is a normal physical block and constitutes a writable area. The number of physical blocks that constitute each of the multiple superblocks in SSD3 is the same. Therefore, the writable size of the superblock SB1 that does not contain any defective areas is the maximum writable size of the superblock.

[0086] Superblock SB2 in Figure 6 is a superblock that includes two bad blocks. In other words, superblock SB2 is a superblock that includes a defective area. Of the storage areas in superblock SB2, the storage areas corresponding to the two bad blocks are defective areas. The other storage areas are writable areas. The writable size of superblock SB2 is the maximum writable size minus the size of the defective areas corresponding to the two bad blocks.

[0087] 6 is a superblock that includes the maximum number of bad blocks permitted in SSD3. In other words, superblock SB3 is the superblock with the largest defective area. The size of the defective area in superblock SB3 is the largest among the sizes of the defective areas in the multiple superblocks in SSD3. In other words, the writable size of superblock SB3 is the smallest among the writable sizes in the multiple superblocks in SSD3.

[0088] In this way, each of the multiple superblocks in SSD 3 can have a different writable size, ranging from the maximum writable size when there is no defective area to the minimum writable size when there is the largest defective area.

[0089] In contrast, in data management conforming to the FDP, the host 2 and SSD 3 determine a fixed size (RU size) for an RU. The same RU size is set for multiple RUs managed between the host 2 and SSD 3. Assuming that one RU is associated with one superblock in the SSD 3, as explained above, it becomes necessary to associate a fixed RU size with a superblock having a writable size between the maximum writable size and the minimum writable size.

[0090] Before describing the correspondence between the writable size of a superblock and the RU size in this embodiment, the correspondence in two comparative examples will be described.

[0091] First, a first comparative example will be described with reference to Fig. 7. Fig. 7 is a diagram illustrating the relationship between superblocks managed in a memory system according to the first comparative example and RU sizes.

[0092] In a first comparative example, the host and the SSD use the maximum writable size of a superblock as the RU size, which is the writable size of a superblock that has no defective areas.

[0093] The memory system in the first comparative example uses only superblocks without defective areas when writing data based on a write command corresponding to the FDP (FDP host write). In other words, only superblocks without defective areas are used as write destination superblocks corresponding to the RUH.

[0094] 7, superblocks SB1, SB2, SB3, etc. are superblocks that do not have any missing areas and can be used as destination superblocks for FDP host writes. Each superblock assigned as a destination superblock is assigned an RU.

[0095] On the other hand, superblocks with defective areas are not used as destination superblocks for FDP host writing. In Figure 7, superblock SB4 and superblock SB5 are superblocks with defective areas. These superblocks are not used for FDP host writing because their writable size is smaller than the RU size.

[0096] In the first comparative example, superblocks with defective areas (superblocks SB4 and SB5 in Figure 7) are not used for FDP host writes, which wastes resources such as physical blocks that can be used to write data in the SSD. This makes it easier for the number of free blocks to fall below the threshold, resulting in increased frequency of garbage collection processes. This also affects the performance of the SSD.

[0097] Next, a second comparative example will be described with reference to Fig. 8. Fig. 8 is a diagram illustrating the relationship between superblocks managed in a memory system according to the second comparative example and RU sizes.

[0098] In the second comparative example, the minimum writable size of a superblock is used as the RU size, which is the writable size of the superblock with the largest missing area.

[0099] The memory system in the second comparative example may use any superblock for FDP host writes. That is, the SSD in the second comparative example may assign the superblock with the largest defect area as the destination superblock corresponding to the RUH. Alternatively, the SSD may assign a superblock with no defect area as the destination superblock corresponding to the RUH.

[0100] However, the host writes only the data of the determined RU size to the write destination RU, so data is not written to some storage areas of the write destination superblock that has a writable size larger than the minimum write size.

[0101] 8, any superblock, such as superblocks SB1, SB2, SB3, etc. that do not have a defective area, or superblocks SB4, SB5, etc. that have a defective area, can be used as a destination superblock for FDP host writes. Each superblock assigned as a destination superblock is assigned an RU.

[0102] Here, because the RU size is the minimum writable size, only the minimum writable size of data is written to the superblock assigned as the destination superblock for FDP host writes. In each superblock, data is not written to the storage area exceeding the minimum writable size. Specifically, in a superblock that does not have a defective area, a storage area the size of the largest defective area is a storage area to which data cannot be written even though it is writable. Furthermore, in a superblock that has a defective area smaller than the largest defective area, a storage area having a size corresponding to the difference between the largest defective area and the actual defective area is a storage area to which data cannot be written even though it is writable.

[0103] These storage areas where data is not written are unused even if data can be written, and therefore become wasted resources within the SSD, which, as in the first comparative example, also affects the performance of the SSD.

[0104] In this way, in both the first and second comparative examples, part of the writable storage area is not used for FDP host writing, which means that SSD resources are wasted.

[0105] In contrast, the SSD 3 according to the embodiment determines the RU size as the maximum writable size, uses an arbitrary superblock for FDP host writing, and writes overflow data to the overflow superblock. This prevents the SSD 3 resources from being wasted in the embodiment.

[0106] The RU size in the SSD 3 according to the embodiment will be described with reference to Fig. 9. Fig. 9 is a diagram showing a write destination superblock in the SSD 3 according to the embodiment.

[0107] In the SSD 3 according to the embodiment and the host 2, as in the first comparative example, the RU size is set to the maximum size among the writable data sizes of each of the multiple super-blocks in the SSD 3. Also, in the SSD 3 according to the embodiment, as in the second comparative example, an arbitrary super-block is assigned as the write destination super-block for FDP host writing.

[0108] If the write destination superblock does not contain a defective area, the controller 4 can write data of the RU size, which is the same as the maximum write size, to the write destination SB. This allows the controller 4 to fully utilize the writable storage area in the write destination SB.

[0109] The controller 4 allocates one superblock to each RU. The controller 4 allocates any superblock as the write destination SB for FDP host writes. Therefore, not only superblocks with no defective areas but also superblocks with defective areas are allocated as write destination SBs. However, the controller 4 may also allocate superblocks with no defective areas as the write destination SB for FDP host writes with priority.

[0110] The controller 4 prepares not only a write destination SB for FDP host writes, but also an overflow super block (SB). The controller 4 allocates any super block as an overflow SB. The overflow SB is a super block into which the remaining data that could not be written to the write destination SB out of the data for the RU size when the FDP host writes is written.

[0111] The controller 4 may write data associated with a normal write command (NonFDP Write) that does not specify an RUH to an overflow SB. Alternatively, the controller 4 may prepare a separate write destination SB for writing data associated with a normal write command. In that case, the controller 4 writes the data associated with the normal write command to that write destination SB.

[0112] In FIG. 9, superblock SB1 is assigned as the write destination SB corresponding to RUH1. Superblock SB2 is assigned as the write destination SB corresponding to RUH2. In FIG. 9, superblock SB1 and superblock SB2 are superblocks that have a defective area. Superblock SB3 is assigned as an overflow SB. Superblock SB3 is a superblock that has no defective area.

[0113] Data having a size corresponding to the defective areas of superblocks SB1 and SB2 (i.e., data remaining unwritten in these superblocks) is written to superblock SB3, which is the overflow SB. Data overflowing from an FDP host write is data that could not be written because the destination superblock has a defective area. The controller 4 stores in the overflow management table 65 the correspondence between the physical address range indicating the storage area into which the overflow data written to overflow superblock SB3 has been written and the original destination superblock. For example, when data overflowing from superblock SB1 is written to superblock SB3, the controller 4 associates information indicating superblock SB1 with the physical address range indicating the storage area into which the overflow data has been written, and stores this in the overflow management table 65. The information indicating the superblock is, for example, a superblock identifier (SBID).

[0114] Here, we will explain the procedure of the initialization process between the host 2 and the SSD 3. Below, we will explain the process for managing the RU size, which is executed when both the host 2 and the SSD 3 support Flexible Data Placement (FDP).

[0115] FIG. 10 is a sequence diagram illustrating management of RU sizes in the memory system according to the embodiment.

[0116] Step 1: SSD 3 provides an RU size to host 2. Here, the RU size is the maximum writable size of a superblock. SSD 3 provides the RU size to host 2 based on a command requesting the RU size received from host 2. Host 2 manages data belonging to the RU based on the provided RU size.

[0117] Step 2-1: The host 2 manages data separately for each RUH for FDP host writes. For example, the host 2 issues one or more write commands when the size of data related to a certain RUH reaches the RU size. The one or more write commands may be multiple write commands, each requesting the writing of a portion of the RU-sized data. Alternatively, the one or more write commands may be a single write command requesting the writing of data equivalent to the RU size. The host 2 may also issue a write command to write a portion of the RU-sized data before the RU-sized data is prepared in the memory 22 of the host 2. When issuing a write command to write a portion of the RU-sized data, the host 2 calculates the remaining size of the write destination RU based on the RU size provided in Step 1.

[0118] Step 2-2: Alternatively, the host 2 sends a command to the SSD 3 requesting the remaining size of the write destination RU. In response to this command, the SSD 3 notifies the host 2 of, for example, Reclaim Unit Available Media Writes (RUAMW) compliant with the NVMe standard. The controller 4, having received this command from the host 2, notifies the host 2 of the size (RUAMW) of the remaining free storage area of ​​the RU specified by this command. The controller 4 calculates the size of the remaining free storage area of ​​the RU, for example, by subtracting from the RU size the size of the data written in the write destination superblock assigned to the specified RU and the total size of the data belonging to the specified RU among the data written in the overflow superblock.

[0119] Next, the write process will be described. Fig. 11 is a first diagram illustrating the write process in the SSD 3 according to the embodiment. First, the writing of data based on a write command specifying RUH1 will be described.

[0120] Step 3: When the size of the data related to RUH1 reaches the RU size, the host 2 issues a write command specifying RUH1 to the SSD 3. The controller 4 of the SSD 3 writes the writable size of data associated with the received write command to the destination superblock SB1 assigned to RUH1. Of the data associated with the received write command, the data in the defective area of ​​the superblock SB1 becomes overflow data.

[0121] Step 4: The controller 4 writes the overflow data from among the data associated with the received write command to the overflow super block SB3. At this time, the controller 4 stores in the overflow management table 65 the correspondence between the information indicating the super block SB1 and the physical address range indicating the storage area where the overflow data has been written.

[0122] Step 5: When the writing of data to superblock SB1 is completed, that is, when there is no more free storage area available for writing in superblock SB1, the controller 4 closes superblock SB1 and then deallocates superblock SB1 to the write destination superblock.

[0123] Step 6: The controller 4 selects the superblock SB4 from the free block list 64. The controller 4 executes the data erasure process on the selected superblock SB4. Then, the controller 4 assigns the selected superblock SB4 as a new write destination superblock.

[0124] Next, a description will be given of writing data based on a write command that specifies RUH2. Fig. 12 is a second diagram illustrating a write process in the SSD 3 according to the embodiment.

[0125] Step 7: The host 2 issues a write command to the SSD 3 to write data related to the RUH 2. Here, it is assumed that a write command associated with data that does not reach the RU size has been issued. The controller 4 of the SSD 3 writes the data associated with the received write command to the write destination superblock SB2 assigned to the RUH 2.

[0126] Step 8: Host 2 issues another write command to SSD 3 to write data related to RUH2. Now, let's assume that the total size of the data associated with the two write commands issued in Steps 7 and 8 reaches the RU size. Controller 4 of SSD 3 writes the data associated with the received write command to destination superblock SB2 assigned to RUH2.

[0127] Step 9: The controller 4 writes the overflow data due to the defective area of ​​the superblock SB2 to the overflow superblock SB3. At this time, the controller 4 stores in the overflow management table 65 the correspondence between the information indicating the superblock SB2 and the physical address range indicating the storage area where the overflow data has been written.

[0128] Thus, in the SSD 3 according to the embodiment, the controller 4 sets the RU size to the maximum writable size of the superblock. The controller 4 uses any superblock, regardless of whether it has a defective area, as the destination superblock for FDP host writing. The controller 4 writes any data that could not be written to the destination superblock to an overflow superblock. This allows the SSD 3 according to the embodiment to efficiently use its resources for FDP host writing.

[0129] Next, the refresh process will be described in detail.

[0130] First, the refresh process in the third comparative example will be described with reference to Fig. 13. Fig. 13 is a diagram showing an example of the refresh process executed in the memory system according to the third comparative example.

[0131] 13(a) shows the state before the refresh process is executed. In this state, superblock SB1 stores only the data of RUH1. Superblock SB2 stores only the data of RUH2. Superblock SB3 stores only the data of RUH3. Superblock SB4 stores only the data of RUH4. Superblock SB5, which is an overflow superblock, stores the data of RUH1, RUH2, RUH3, and RUH4.

[0132] Now, the refresh process in the third comparative example is executed. Here, it is assumed that superblocks SB1, SB2, SB3, SB4, and SB5 are selected as superblocks to be refreshed. In the refresh process, the controller writes the data stored in the superblocks to be refreshed to the destination superblock. Here, superblocks SB6, SB7, SB8, SB9, and SB10 are the destination superblocks.

[0133] In FIG. 13(b), data stored in superblocks SB1, SB2, SB3, SB4, and SB5 to be refreshed is moved to superblocks SB6, SB7, SB8, SB9, and SB10, which are the destination superblocks.

[0134] Specifically, the controller writes the data for RUH1 that was stored in superblock SB1 to superblock SB6. Then, the controller writes part of the data for RUH2 that was stored in superblock SB2 to the remaining storage area of ​​superblock SB6. As a result, the data for RUH1 and the data for RUH2 are stored in superblock SB6. This mixture of data occurs because the superblock SB1 to be refreshed contains a defective area, while the destination superblock SB6 does not contain a defective area.

[0135] The controller writes the remaining data of RUH2 that was stored in superblock SB2 to the destination superblock SB7. Then, the controller writes part of the data of RUH3 that was stored in superblock SB3 to the remaining storage area of ​​superblock SB7. As a result, the data of RUH2 and the data of RUH3 are stored in superblock SB7. This mixture of data occurs because part of the data of RUH2 was moved from superblock SB2 to superblock SB6 and because the size of the missing area in superblock SB7 is smaller than the size of the missing area in superblock SB2.

[0136] The controller writes the remaining data of RUH3 that was stored in superblock SB3 to the destination superblock SB8. Then, the controller writes part of the data of RUH4 that was stored in superblock SB4 to the remaining storage area of ​​superblock SB8. As a result, the data of RUH3 and the data of RUH4 are stored in superblock SB8. This mixing of data occurs because part of the data of RUH3 that was stored in superblock SB3 was moved to superblock SB7.

[0137] The controller writes the remainder of the data in RUH4 that was stored in superblock SB4 to the destination superblock SB9. Then, the controller writes the data in RUH1 and part of the data in RUH2 that were stored in superblock SB5 to the remaining storage area of ​​superblock SB9. As a result, the data in RUH4, the data in RUH1, and the data in RUH2 are stored in superblock SB9. This mixture of data occurs because part of the data in RUH4 that was stored in superblock SB4 has been moved to superblock SB8, and because the data stored in overflow superblock SB5 has been moved to superblock SB9.

[0138] The controller writes the remaining data of RUH2 that was stored in superblock SB5, as well as the data of RUH3 and RUH4, to the destination superblock SB10. As a result, the data of RUH2, RUH3 and RUH4 are stored in superblock SB10.

[0139] It is assumed that the data in RUH2 is then invalidated. For example, the host transmits a trim command specifying the data in RUH2 to the memory system, thereby invalidating the data in RUH2.

[0140] (c) of Fig. 13 is a diagram showing a state in which the data in RUH2 has been invalidated. As a result of the data in RUH2 being invalidated, superblock SB10, which stored the data in RUH2 in (b) of Fig. 13, becomes a superblock storing invalid data in (c) of Fig. 13.

[0141] Specifically, superblocks SB6, SB7, SB9, and SB10 are superblocks that store invalid data. Furthermore, each of these superblocks still stores other valid data. Therefore, even if the data in RUH2 is invalidated, these superblocks do not become reusable blocks (free blocks).

[0142] Next, a description will be given of the refresh process executed in the SSD 3 according to the embodiment. In the SSD 3 according to the embodiment, the refresh process may be executed using information stored in the overflow management table 65 as well.

[0143] FIG. 14 is a diagram showing an example of a refresh process executed in the SSD 3 according to the embodiment.

[0144] 14(a) shows the state before the refresh process is executed. In this state, superblock SB1 stores only the data of RUH1. Superblock SB2 stores only the data of RUH2. Superblock SB3 stores only the data of RUH3. Superblock SB4 stores only the data of RUH4. Superblock SB5, which is an overflow superblock, stores the data of RUH1, RUH2, RUH3, and RUH4.

[0145] The overflow management table 65 stores information about overflow data stored in the overflow superblock SB5. Specifically, data overflowing from superblock SB1 is stored in a storage area indicated by the physical address range n to m. Data overflowing from superblock SB2 is stored in a storage area indicated by the physical address range m to o. Data overflowing from superblock SB3 is stored in a storage area indicated by the physical address range o to p. Data overflowing from superblock SB4 is stored in a storage area indicated by the physical address range p to q. Because superblock SB5 is an overflow superblock, information about the overflow data corresponding to it is not stored in the overflow management table 65.

[0146] Here, the refresh process in the embodiment is executed. Here, it is assumed that superblocks SB1, SB2, SB3, SB4, and SB5 are selected as superblocks to be refreshed.

[0147] 14(b), the controller 4 refers to the overflow management table 65 and moves data from the super-blocks SB1, SB2, SB3, SB4, and SB5 to be refreshed to the super-blocks SB6, SB7, SB8, and SB9 as the destinations. In addition, the controller 4 assigns the super-block SB10 as a new overflow super-block during the refresh process.

[0148] The controller 4 writes the RUH1 data that was stored in superblock SB1 to superblock SB6. Then, the controller 4 writes the RUH1 data that was stored in superblock SB5 to the remaining storage area of ​​superblock SB6. In other words, the RUH1 data that was stored in superblock SB1 and the RUH1 data that was stored in overflow superblock SB5 are moved to superblock SB6. As a result, superblock SB6 becomes a superblock in which only the RUH1 data is stored.

[0149] The controller 4 writes the data of RUH2 that was stored in superblock SB2 to superblock SB7. Then, the controller 4 writes part of the data of RUH2 that was stored in superblock SB5 to the remaining storage area of ​​superblock SB7. That is, the data of RUH2 that was stored in superblock SB2 and part of the data of RUH2 that was stored in overflow superblock SB5 are moved to superblock SB7. As a result, superblock SB7 becomes a superblock that stores only the data of RUH2. Because the destination superblock SB7 includes a defective area, the remaining data of RUH2 that was stored in superblock SB5 becomes overflow data. The controller 4 writes this overflow data to a new overflow superblock SB10. Then, the controller 4 stores in the overflow management table 65 the correspondence between information indicating superblock SB7 and the physical address range r to s that indicates the storage area where the overflow data has been written.

[0150] The controller 4 writes the data of RUH3 that was stored in superblock SB3 to superblock SB8. Then, the controller 4 writes part of the data of RUH3 that was stored in superblock SB5 to the remaining storage area of ​​superblock SB8. That is, the data of RUH3 that was stored in superblock SB3 and part of the data of RUH3 that was stored in overflow superblock SB5 are moved to superblock SB8. As a result, superblock SB8 becomes a superblock that stores only the data of RUH3. Because the destination superblock SB8 includes a defective area, the remaining data of RUH3 that was stored in superblock SB5 becomes overflow data. The controller 4 writes this overflow data to a new overflow superblock SB10. Then, the controller 4 stores in the overflow management table 65 the correspondence between information indicating superblock SB8 and the physical address range s to t that indicates the storage area where the overflow data has been written.

[0151] The controller 4 writes the data of RUH4 that was stored in superblock SB4 to superblock SB9. Then, the controller 4 writes part of the data of RUH4 that was stored in superblock SB5 to the remaining storage area of ​​superblock SB9. In other words, the data of RUH4 that was stored in superblock SB4 and part of the data of RUH4 that was stored in overflow superblock SB5 are moved to superblock SB9. As a result, superblock SB9 becomes a superblock that stores only the data of RUH4. Because the destination superblock SB9 includes a defective area, the remaining data of RUH4 that was stored in superblock SB5 becomes overflow data. The controller 4 writes this overflow data to a new overflow superblock SB10. Then, the controller 4 stores in the overflow management table 65 the correspondence between information indicating superblock SB9 and the physical address range t to u that indicates the storage area where the overflow data has been written.

[0152] Superblock SB10 is a new overflow superblock that stores the data of RUH2, RUH3, and RUH4. The controller 4 stores the remaining data of RUH2, RUH3, and RUH4 that were stored in superblock SB5 in the refresh destination superblock SB10. Specifically, the data that overflowed from superblock SB7 is stored in the storage area indicated by the physical address range r to s. The data that overflowed from superblock SB8 is stored in the storage area indicated by the physical address range s to t. The data that overflowed from superblock SB9 is stored in the storage area indicated by the physical address range t to u.

[0153] Thus, in the refresh process in the SSD 3 according to the embodiment, the controller 4 writes to the destination super-block the data belonging to the first RU stored in the super-block to be refreshed and the data belonging to the first RU stored in the overflow super-block, the data corresponding to the size of the writable area of ​​the destination super-block. If there is remaining data that could not be written to the destination super-block, the controller 4 writes this remaining data to a new overflow super-block.

[0154] It is assumed that the data in RUH2 is then invalidated. For example, the host 2 sends a trim command specifying the data in RUH2 to SSD3, thereby invalidating the data in RUH2.

[0155] Figure 14(c) is a diagram showing a state in which the data in RUH2 has been invalidated. As a result of the invalidation of the data in RUH2, superblock SB7, which stored only the data in RUH2 in Figure 14(b), becomes a superblock that stores only invalid data. Also, superblock SB10, which stored the data in RUH2 in Figure 14(b), becomes a superblock that stores invalid data in Figure 14(c).

[0156] In other words, superblock SB7 is registered in the free block list 64 as a free block that stores only invalid data. New data can be written to superblock SB7 again by executing a data erasure process. In other words, superblock SB7 is a reusable superblock.

[0157] Since superblock SB10 has stored overflow data other than the data of RUH2, it is a superblock that stores valid data and invalid data, and therefore superblock SB10 is not yet a reusable superblock.

[0158] Next, the garbage collection (GC) process executed in this embodiment will be described. Two types of GC process executed in the SSD 3 according to this embodiment will be described with reference to Fig. 15 and Fig. 16.

[0159] First, the GC process according to the first method will be described with reference to Fig. 15. Fig. 15 is a diagram showing a first example of the garbage collection process executed in the memory system according to the embodiment.

[0160] Figure 15(a) shows the state before GC processing is performed. Here, we assume that host 2 has overwritten data in an LBA range corresponding to part of the data belonging to a certain RU, or invalidated the same range using a trim command. Note that if host 2 correctly supports FDP, such a case is unlikely to occur.

[0161] Superblock SB1 stores the data of RUH1 and invalid data. Superblock SB2 stores the data of RUH2 and invalid data. Superblock SB3 stores the data of RUH1 and data of RUH2.

[0162] Superblock SB1 is the write destination superblock for RUH1. Some of the data for RUH1 in superblock SB1 has been overwritten or invalidated, making it invalid. The overflow data from superblock SB1 is stored in a storage area in superblock SB3, indicated by the physical address range n to m.

[0163] Superblock SB2 is the write destination superblock for RUH2. Some of the data for RUH2 in superblock SB2 has been overwritten or invalidated, making it invalid. The overflow data from superblock SB2 is stored in a storage area in superblock SB3 indicated by the physical address range m to o.

[0164] Next, the controller 4 executes the GC process.

[0165] In the GC process according to the first method, the controller 4 copies data so that data belonging to the same RU are consecutive in physical addresses in the GC destination superblock.

[0166] 15(b) shows the state after GC processing by the first method has been executed. In this GC processing, the controller 4 selects superblocks SB1 and SB2 as GC source superblocks. Then, the controller 4 selects superblock SB4 from the free block list 64 as a GC destination superblock. The controller 4 registers the selected superblock SB4 in the active block list 63.

[0167] The controller 4 copies the valid data of RUH1 stored in superblock SB1 and the valid data of RUH1 stored in superblock SB3 to superblock SB4. Furthermore, in response to the fact that there is still free storage space in the GC destination superblock SB4, the controller 4 copies the valid data of RUH2 stored in superblock SB2 and the valid data of RUH2 stored in superblock SB3 to superblock SB4.

[0168] As a result of the GC process, superblocks SB1 and SB2 become free blocks that do not store valid data. In addition, the controller 4 updates the overflow management table 65 and deletes the information on the physical address ranges of the overflow data that correspond to superblocks SB1 and SB2.

[0169] Furthermore, the data in RUH1 and RUH2 stored in overflow superblock SB3 both become invalid. However, because superblock SB3 is an overflow superblock with free storage space to which data can be written, other overflow data may be added. Furthermore, if the overflow superblock is also used as a superblock to which data associated with a normal write command is written, the controller 4 writes the data associated with the received normal write command to the free storage space in superblock SB3 in response to receiving the normal write command. In other words, the controller 4 maintains superblock SB3 as an overflow superblock.

[0170] Next, the GC process according to the second method will be described. Fig. 16 is a diagram showing a second example of the garbage collection process executed in the SSD 3 according to the embodiment.

[0171] The state shown in FIG. 16(a) is the same as the state before the GC process described in FIG. 15(a) is executed.

[0172] In the second method of GC processing, valid data stored in the GC source superblock is copied to the overflow superblock.

[0173] 16(b) shows the state after GC processing by the second method has been executed. In GC processing by the second method, the controller 4 selects superblocks SB1 and SB2 as GC source superblocks, as in GC processing by the first method. Then, the controller 4 selects superblock SB3, which is an overflow superblock, as GC destination superblock.

[0174] In (b) of Figure 16, the controller 4 copies valid data from superblocks SB1 and SB2 that are the GC sources to overflow superblock SB3. Specifically, the controller 4 reads the valid data of RUH1 stored in superblock SB1. The controller 4 writes the read valid data to a free storage area in superblock SB3. The controller 4 also reads the valid data of RUH2 stored in superblock SB2. The controller 4 writes the read valid data to superblock SB3.

[0175] As a result, both the data in RUH1 and the data in RUH2 are stored only in superblock SB3. Therefore, the controller 4 deletes the information related to superblocks SB1 and SB2 from the overflow management table 65.

[0176] According to the GC process of this embodiment, whether the first or second method is used, superblocks SB1 and SB2 become free blocks, and the data in RUH1 and RUH2 are stored in the GC target superblock.

[0177] Next, the procedure of the write process will be described.

[0178] FIG. 17 is a flowchart showing the procedure of the write process executed in the SSD 3 according to the embodiment.

[0179] First, the controller 4 of the SSD 3 receives a write command from the host 2 (S101). In response to receiving the write command, the controller 4 starts the write process.

[0180] The controller 4 determines whether or not the write command received in step S101 is a write command that specifies an RUH (S102). In other words, the controller 4 determines whether or not the write command received in step S101 is a write command that requests writing of data that complies with the FDP.

[0181] If the received write command is a write command that specifies an RUH (Yes in S102), the controller 4 starts write processing that complies with the FDP. Here, it is assumed that the write command that specifies an RUH is a command that requests the writing of data of an RU size. The controller 4 writes the data associated with the write command to the write destination superblock that corresponds to the specified RUH (S103).

[0182] The controller 4 determines whether or not there is a defective area in the write destination super-block in step S103 (S104). That is, the controller 4 determines whether or not the write destination super-block can store all of the data of the RU size.

[0183] If the write destination super-block has a defective area (Yes in S104), the controller 4 writes data corresponding to the size of the defective area to the overflow super-block (S105).

[0184] The controller 4 records information related to the data written in step S105 in the overflow management table 65 (S106). In the overflow management table 65, information indicating the write destination superblock is associated with a physical address range indicating the storage area into which the overflow data was written in step S105.

[0185] The controller 4 completes the write process and sends a completion response corresponding to the write command received in step S101 to the host 2 (S107).

[0186] If there is no defective area in the write destination super-block (No in S104), the controller 4 completes the write process and sends a completion response corresponding to the write command received in step S101 to the host 2 (S107). At this time, the write destination super-block stores all of the RU-sized data.

[0187] If the write command received in step S101 is not a write command that specifies an RUH (No in S102), the controller 4 writes the data associated with the received write command to the overflow super block (S108).

[0188] Then, the controller 4 completes the write process and sends a completion response corresponding to the write command received in step S101 to the host 2 (S107).

[0189] Next, the refresh process will be described.

[0190] FIG. 18 is a flowchart showing the procedure of the refresh process executed in the SSD 3 according to the embodiment.

[0191] First, the controller 4 of the SSD 3 selects a superblock to be refreshed (S201).

[0192] The controller 4 refers to the overflow management table 65 for the superblock to be refreshed selected in step S201 (S202).

[0193] The controller 4 determines whether or not there is overflow data corresponding to the superblock to be refreshed selected in step S201 (S203). For example, the controller 4 determines whether or not the physical address range indicating the storage area in which the overflow data corresponding to the superblock to be refreshed selected in step S201 is stored is included in the overflow management table 65 referenced in step S202.

[0194] If overflow data exists (Yes in S203), the controller 4 writes the data stored in the super-block to be refreshed and the overflow data that belongs to the same RU as this data to the destination super-block (S204).

[0195] If there is no overflow data (No in S203), the controller 4 writes the data stored in the super-block to be refreshed to the destination super-block (S205).

[0196] The controller 4 determines whether or not there is a missing area in the destination super-block (S206). That is, the controller 4 determines whether or not the destination super-block is capable of storing all of the data of the RU size.

[0197] If the destination super-block has a defective area (Yes in S206), the controller 4 writes data corresponding to the size of the defective area to the overflow super-block (S207). The controller 4 writes the remaining data that could not be written to the destination super-block due to the defective area to the overflow super-block.

[0198] The controller 4 records information about the overflow data written to the overflow super block in step S207 in the overflow management table 65 (S208). In the overflow management table 65, information indicating the destination super block is associated with a physical address range indicating the storage area into which the overflow data was written in step S207.

[0199] If there is no defective area in the destination super block (No in S206), the controller 4 skips the processes of steps S207 and S208 because no overflow data will occur.

[0200] The controller 4 determines whether the refresh process is complete (S209). The controller 4 determines whether there are any other superblocks that require refresh process.

[0201] If the refresh process is completed (Yes in S209), the controller 4 ends the refresh process.

[0202] If there is another super block that requires refresh processing (No in S209), the controller 4 selects another super block to be refreshed (S201).

[0203] Next, the garbage collection process will be described.

[0204] 19 is a flowchart showing the procedure of the garbage collection process executed in the SSD 3 according to the embodiment. Here, it is assumed that the GC process is executed by the first method.

[0205] The controller 4 of the SSD 3 selects a GC source super block (S301). For example, the controller 4 selects one or more super blocks that have a low ratio of valid data from among the super blocks registered in the active block list 63 as GC source super blocks.

[0206] The controller 4 refers to the overflow management table 65 for the GC source super block selected in step S301 (S302).

[0207] The controller 4 determines whether or not there is overflow data corresponding to the GC source super-block selected in step S301 (S303). For example, the controller 4 determines whether or not the physical address range indicating the storage area in which the overflow data corresponding to the GC source super-block selected in step S301 is stored is included in the overflow management table 65 referenced in step S302.

[0208] If overflow data exists (Yes in S303), the controller 4 writes the data stored in the GC source super block and the overflow data that belongs to the same RU as this data to the GC destination super block (S304).

[0209] If there is no overflow data (No in S303), the controller 4 writes the data stored in the GC source super block to the GC destination super block (S305).

[0210] The GC destination super-block in steps S304 and S305 may be, for example, a super-block newly selected from the free block list 64, or an overflow super-block.

[0211] The controller 4 determines whether or not data belonging to one RU has been stored in one superblock (S306). In other words, the controller 4 determines whether or not overflow data has occurred.

[0212] If the data belonging to one RU is stored in one GC destination super-block (Yes in S306), that is, if no overflow data occurs, the controller 4 completes writing of the data stored in the GC source super-block selected in step S301 (S307).

[0213] If the data belonging to one RU is not stored in one GC destination super-block (No in S306), that is, if overflow data occurs, the controller 4 writes the overflow data to a new GC destination super-block (S308). The controller 4 writes the data that could not be written to the original GC destination super-block to the new GC destination super-block.

[0214] The controller 4 records information about the overflow data written in step S308 in the overflow management table 65 (S309).

[0215] Then, the controller 4 completes writing of the data stored in the GC source super block selected in step S301 (S307).

[0216] When GC processing is performed using the second method, the controller 4 writes the valid data stored in the GC source super-block to the overflow super-block, regardless of the result of the determination in step S303.

[0217] As a result, in the garbage collection process, the controller 4 links the data stored in the GC source super block with the overflow data corresponding to this GC source super block, and executes a data copy.

[0218] As described above, in the SSD 3 according to the embodiment, the controller 4 sets the RU size as the maximum writable size of a superblock, and assigns any superblock as a write destination superblock in a data write process conforming to the FDP. When overflow data occurs, the controller 4 writes the overflow data to the overflow superblock.

[0219] This allows the controller 4 to use the writable storage area of ​​the superblock in the SSD 3 for data write processing in accordance with the FDP without wasting it.

[0220] In addition, during refresh processing and garbage collection processing, the controller 4 links the data stored in the target superblock with the overflow data corresponding to the target superblock and copies them to the destination superblock (or GC destination superblock).

[0221] This makes it possible to prevent data from multiple RUs from being mixed together in one superblock when data is moved.

[0222] Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included within the scope and spirit of the invention, and are also included in the scope of the invention and its equivalents as defined in the claims. [Explanation of symbols]

[0223] 1...information processing system, 2...host, 3...memory system, 4...controller, 5...NAND flash memory, 6...DRAM, 21...processor, 22...memory, 41...host interface circuit, 42...CPU, 43...SRAM, 44...DMAC, 45...ECC circuit, 46...NAND interface circuit, 47...DRAM interface circuit, 61...L2P table, 62...block management table, 63...active block list, 64...free block list, 65...overflow management table, 421...write control circuit, 422...refresh control circuit, 423...garbage collection control circuit.

Claims

1. 1. A memory system connectable to a host, comprising: a nonvolatile memory including a plurality of physical blocks, each of which is a unit of a data erasure operation; a controller electrically connected to the non-volatile memory; The controller managing a plurality of superblocks, each including one or more physical blocks of the plurality of physical blocks, and including at least a first superblock and a second superblock; setting a first size, which is a size of a data management unit by the host, to a maximum size among data sizes that can be written to each of the plurality of super-blocks; notifying the host of the set first size; In response to receiving one or more write commands from the host specifying a first management unit having the first size, writing data of a second size, which is a data size that can be written to the first super-block, from among the data belonging to the first management unit, to the first super-block; and writing data of a third size, which is the difference between the first size and the second size, from among the data belonging to the first management unit, to the second super-block. Memory system.

2. the plurality of superblocks further includes a third superblock and a fourth superblock; The controller In a first process on the first superblock, writing data of a fourth size, which is a data size that can be written to the third super-block, out of the data belonging to the first management unit stored in the first super-block and the data belonging to the first management unit stored in the second super-block, to the third super-block, and writing data of a fifth size, which is a difference between the first size and the fourth size, to the fourth super-block.

10. The memory system of claim 1.

3. the plurality of super-blocks further includes a third super-block; The controller In a second process on the first super-block, and writing, to the third super-block, valid data of the data belonging to the first management unit stored in the first super-block and valid data of the data belonging to the first management unit stored in the second super-block.

10. The memory system of claim 1.

4. The controller In a second process on the first super-block, and writing valid data of the data belonging to the first management unit stored in the first super-block to the second super-block storing the valid data of the data belonging to the first management unit.

10. The memory system of claim 1.

5. the management unit is a Reclaim Unit (RU), Data belonging to one RU is associated with multiple logical block addresses (LBAs).

10. The memory system of claim 1.

6. The controller and in response to receiving, from the host, a write command that does not specify a destination RU, writing data associated with the write command that does not specify a destination RU to the second super-block.

6. The memory system of claim 5.

7. The controller when the data of the third size is written to the second super-block, and storing, in a first table, a correspondence between the first superblock and a physical address range indicating a storage area within the second superblock to which the data of the third size is written.

10. The memory system of claim 1.

8. the plurality of superblocks further includes a third superblock and a fourth superblock; The controller In a first process on the first superblock, writing data of a fourth size, which is a data size that can be written to the third superblock, out of the data belonging to the first management unit stored in the first superblock and the data stored in a storage area indicated by the physical address range in the first table to which the data of the third size has been written, to the third superblock, and writing data of a fifth size, which is a difference between the first size and the fourth size, to the fourth superblock; and storing, in the first table, a correspondence between the third superblock and a physical address range indicating a storage area within the fourth superblock to which the fifth size of data is written.

8. The memory system of claim 7.

9. the plurality of superblocks further includes a third superblock and a fourth superblock; The controller In a second process on the first super-block, writing data of a fourth size, which is a data size writable to the third super-block, out of first valid data that is valid data of data belonging to the first management unit stored in the first super-block and second valid data that is valid data of data stored in a storage area indicated by a physical address range in the first table to which the data of the third size has been written, to the third super-block; and writing data of a sixth size, which is a difference between a fifth size that is a total size of the first valid data and the second valid data, and the fourth size, to the fourth super-block.

8. The memory system of claim 7.

10. The controller and notifying the host of a difference between the first size and a total size of the second size and the third size in response to receiving a first request specifying the first management unit from the host.

10. The memory system of claim 1.

Images