Method for managing a namespace in a storage device and a storage device using the method

Abstract

To provide a method for managing a name space in a storage device, and a storage device for using the method.SOLUTION: A storage device includes a memory, and a controller connected to the memory. The controller includes: a host interface layer (HIL); and a flash transformation layer that is configured to report, to the HIL, a first OP chunk from an over-provisioning (OP) pool and a first chunk separate from the OP pool. The storage device receives, at the HIL, a command, and uses a portion of the memory for a first name space from a plurality of name spaces. The first name space includes chunks that are not aligned. The controller uses the first OP chunks as chunks that are not aligned in the first name space. The number of OP chunks which are used as the chunks that are not aligned is smaller than the number of the plurality of name spaces.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a method for managing a namespace in a storage device and a storage device using the method.

Background Art

[0002] Recently, with the development of computer technology, electronic devices have been introduced into all aspects of life. As the amount of electronically stored information (such as photos, videos, music, documents, etc.) increases exponentially (rapidly), the user's demand for storage capacity is increasing. However, software and / or hardware limitations cause a loss of capacity when allocating namespaces requested by users. Therefore, efforts are being made to meet the user's demands (needs) while reducing the loss of capacity.

[0003] The development of recent storage technologies, especially solid state storage devices (solid - state drives (SSDs)), provides various advantages compared to existing mechanical storage devices such as hard disk drives (HDDs). Furthermore, new protocols for accessing data stored in a new generation of storage devices have been developed, including the NVMe (Non - Volatile Memory Express) protocol.

[0004] The above - disclosed information in this background art is for helping the understanding of the background art of the present invention and may include information that does not constitute the prior art.

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0006] The present invention has been made in view of the above prior art, and an object of the present invention is to provide a method for managing a namespace in a storage device and a storage device using the method.

Means for Solving the Problems

[0007] A storage device according to an aspect of the present invention made to achieve the above object is a storage device configured to support a plurality of namespaces, including a memory and a controller connected to the memory. The controller includes a host interface layer and a flash translation layer configured to report a first over-provisioning chunk from an over-provisioning pool and a first chunk separate from the over-provisioning pool to the host interface layer. The controller is configured to receive a command at the host interface layer and use a part of the memory for a first namespace from among the plurality of namespaces. The first namespace includes unaligned chunks, and the controller is configured to use the first over-provisioning chunk as the unaligned chunk of the first namespace. The number of over-provisioning chunks used as unaligned chunks is less than the number of the plurality of namespaces.

[0008] The controller further includes an internal memory, and preferably, the number of over-provisioning chunks used as the unaligned chunks is based on the amount of the internal memory of the controller.

[0009] The type of the memory of the storage device is a triple-level cell flash, a quad-level cell flash, or a Z-NAND type, and preferably, the plurality of namespaces are based on the type of the memory.

[0010] The host interface layer includes a visible chunk pool including the first chunk and a hidden chunk pool including the first over-provisioning chunk. The host interface layer is configured to report information about the visible chunk pool to the host and hide information about the hidden chunk pool from the host. The host may be configured to send the command to the storage device to use the portion of the memory for the first namespace from among the plurality of namespaces.

[0011] The controller may be further configured to utilize the first over-provisioning chunk for the first namespace in a first-come, first-served order.

[0012] The controller may be further configured to use the first over-provisioning chunk based on a privacy designation, format, or group number of the first namespace.

[0013] The controller may be further configured to use the first over-provisioning chunk based on whether a potential capacity loss of the first namespace associated with the first namespace is higher or lower than a set threshold.

[0014] The controller may be further configured to use the first over-provisioning chunk based on whether a size of the first namespace is higher or lower than a set threshold.

[0015] A system according to an aspect of the present invention made to achieve the above object includes a storage device and a host configured to send the command to the storage device to use the portion of the memory for the first namespace from among the plurality of namespaces.

[0016] A method according to one aspect of the present invention made to achieve the above object is a method for managing a namespace in a storage device, the method including: supporting a plurality of namespaces by the storage device; reporting, by a flash translation layer of a controller of the storage device, a first over-provisioning chunk from an over-provisioning pool and a first chunk separate from the over-provisioning pool to a host interface layer of the controller of the storage device; receiving, by the storage device, a command at the host interface layer and using a part of memory for a first namespace from among the plurality of namespaces, the first namespace including unaligned chunks; and using, by the controller, the first over-provisioning chunk as the unaligned chunk of the first namespace, wherein the number of over-provisioning chunks used as unaligned chunks is less than the number of the plurality of namespaces.

[0017] The method further includes supporting, by the controller, the number of over-provisioning chunks used as the unaligned chunks, and the number of over-provisioning chunks is preferably based on an amount of internal memory of the controller.

[0018] The method further includes supporting the plurality of namespaces based on a type of the memory of the storage device, and the type of the memory can be a triple-level cell flash, a quad-level cell flash, or a Z-NAND type.

[0019] The method may further include: reporting, by the host interface layer, information about the invisible chunk pool including the first chunk to the host; hiding, by the host interface layer, information about the hidden chunk pool including the first over-provisioning chunk from the host; and sending, by the host, the command to the storage device to utilize the portion of the memory for the first namespace from among the plurality of namespaces.

[0020] The method may further include: utilizing, by the controller, the first over-provisioning chunk for the first namespace in a first-come, first-served order.

[0021] The method may further include: utilizing, by the controller, the first over-provisioning chunk based on the privacy designation, formatting, or group number of the first namespace.

[0022] The method may further include: utilizing, by the controller, the first over-provisioning chunk based on whether a potential capacity loss of the first namespace associated with the first namespace is higher or lower than a set threshold.

[0023] The method may further include: utilizing, by the controller, the first over-provisioning chunk based on whether the size of the first namespace is higher or lower than a set threshold.

[0024] A method according to another aspect of the present invention made to achieve the above object is a method for managing a namespace in a storage device including a memory and the controller, where the controller includes a host interface layer and a flash translation layer, and the flash translation layer reports a first over-provisioning chunk from an over-provisioning pool and a first chunk separate from the over-provisioning pool to the host interface layer; a step in which the controller receives a first command at the host interface layer and uses a first portion of the memory for a first namespace, the first namespace including a first unaligned chunk associated with a first potential capacity loss; a step in which the controller uses the first over-provisioning chunk as the first unaligned chunk of the first namespace; a step in which the controller receives a second command at the host interface layer and uses a second portion of the memory for a second namespace, the second namespace including a second unaligned chunk; and a step in which the controller uses the first chunk as the second unaligned chunk of the second namespace.

[0025] The method further includes a step in which the controller supports a plurality of over-provisioning chunks used as unaligned chunks, and the plurality of over-provisioning chunks are preferably based on the amount of internal memory of the controller.

[0026] The method further includes a step in which the storage device supports a plurality of namespaces based on the type of the memory of the storage device, and the type of the memory can be a triple-level cell flash, a quad-level cell flash, or a Z-NAND type.

[0027] The method may further include: reporting, by the host interface layer, information about a visible chunk pool including the first chunk to a host; hiding, by the host interface layer, information about a hidden chunk pool including the first over-provisioning chunk from the host; sending, by the host, the first command to the storage device to utilize the first portion of the memory for the first namespace; and sending, by the host, the second command to the storage device to utilize the first portion of the memory for the second namespace.

Advantages of the Invention

[0028] According to the present invention, it is possible to reduce the capacity loss associated with the generation of a namespace in a storage device. Further, according to the present invention, it is possible to provide a namespace management system and method that can provide a logical block size granularity to prevent capacity loss. Furthermore, according to the present invention, based on one or more factors, by providing a logical block size granularity, there is an effect that logic for static and dynamic adjustment of a namespace for avoiding capacity loss is provided.

Brief Description of the Drawings

[0029]

Figure 1

Figure 2A

Figure 2B

Figure 2C

Figure 3A

Figure 3B

Figure 3C

Figure 4A

Figure 4B

Embodiments for Carrying Out the Invention

[0030] Hereinafter, embodiments of the present invention will be described in more detail with reference to the drawings, where the same reference numerals refer to the same components throughout. However, the present invention can be embodied in many other forms and is not limited to the embodiments disclosed herein. Rather, these embodiments are provided by way of example, so that this disclosure will be thorough and complete, and will fully convey the aspects and features of the present invention to those of ordinary skill in the art. Therefore, processes, components, and techniques that are not necessary for a complete understanding of the aspects and features of the present invention by those of ordinary skill in the art will not be described. Unless otherwise explicitly stated, the same reference numerals indicate the same components throughout the drawings and the description of the description, so the description will not be repeated.

[0031] Generally, a host requests a storage device to create a namespace. A "namespace" refers to the amount of non-volatile memory that is formatted into logical blocks, where the size of the namespace is the same as the size of the combined "n" logical blocks. As used herein, a "logical block" means the smallest unit of an I / O command (e.g., read and write commands) for data addressing in the NVMe specification, and each logical block of the namespace has a corresponding LBA (e.g., LBAs from 0 to (n - 1)).

[0032] The creation of multiple namespaces is useful to a host for various reasons. For example, namespaces provide logical separation, multi-tenancy, security isolation, etc. To create a namespace, the host sends a request to a controller of the storage device that specifies the attributes of the namespace (e.g., the format of the namespace, the group number associated with the namespace, shared or privacy designation, the range of logical block addresses, etc.).

[0033] In response to the request, the controller of the storage device uses a chunk of memory for the namespace. A "chunk" (i.e., a range of logical page numbers (LPN)) refers to the smallest addressing unit supported by the hardware of the storage device when using the storage device's memory for the namespace.

[0034] Since the size of the logical block requested by the host may not match the size of the chunk, the host may divide by a multiple of the size of one chunk or request multiple logical blocks corresponding to the total size that is a multiple of the size of one chunk. Thus, the total size of the logical blocks requested for the namespace may not be aligned (i.e., may not be the same) with the size of one or more chunks used for the namespace. In this way, unaligned chunks (i.e., chunks that are only partially addressed by the namespace) have a portion of the unaligned chunk not addressed and used by the controller of the storage device. For example, since the host did not provide a logical block and associated LBA corresponding to the full capacity of the chunk, a portion of the unaligned chunk cannot be addressed. The portion of the unaligned chunk that cannot be addressed results in a loss of capacity of the storage device.

[0035] As a non-limiting example, the host requests the generation of two namespaces, each having a size of 256 kilobytes (KB). However, the storage device may not recognize memory chunks that are exactly equal to 256 KB, either individually or collectively (i.e., one or more chunks). For example, the storage device has hardware that supports a chunk size of 1 gigabyte (GB). The first chunk is used for the first namespace of the two namespaces, and the second chunk is used for the second namespace of the two namespaces. The 256 KB of the first chunk can be addressed as part of the first namespace (e.g., by the host), but the remaining 999.744 MB of the first chunk cannot be addressed. Similarly, the 256 KB of the second chunk can be addressed as part of the second namespace, but the remaining 999.744 MB of the second chunk cannot be addressed. Therefore, each namespace results in 999.744 MB of storage device that cannot be addressed. That is, the size difference between 1 GB and 256 KB is not addressable for each of the two namespaces. Thus, when generating two 256 KB namespaces, in this case, a capacity loss of 1.999488 GB of the storage device occurs.

[0036] As another non-limiting example, the host requests the generation of a namespace with a size of 1.1 GB. In this non-limiting example, the storage device recognizes 1 GB chunks and uses two chunks to accommodate the 1.1 GB sized namespace. For example, the first chunk accommodates a 1 GB namespace, and the second chunk accommodates a 0.1 GB namespace. The remaining 0.9 GB of the second chunk cannot be addressed. Therefore, the namespace results in 0.9 GB of storage device that cannot be addressed. Thus, in this case, when generating the namespace, a capacity loss of 0.9 GB of the storage device occurs.

[0037] According to one or more embodiments of the present invention, a controller of a storage device uses a chunk of an over-provisioning pool (OP pool) as an unaligned chunk to prevent loss of capacity and achieve logical block size granularity. That is, the chunk of the OP pool absorbs the unaligned chunk. Since the unaligned chunk of the OP pool is generally maintained in an unmapped state, no OP loss occurs. That is, using the chunk of the OP pool for the unaligned chunk of the namespace does not affect the operations performed in the OP pool of the storage device, such as wear leveling, garbage collection, and the like.

[0038] Furthermore, in one or more embodiments of the present invention, the controller of the storage device supports fewer chunks from the OP pool used as unaligned chunks than the total count of namespaces supported by the storage device. Therefore, in some namespaces, the logical block size granularity is provided using the chunks of the OP pool, and in some namespaces, the chunk size granularity is provided.

[0039] In one or more embodiments, the controller of the storage device uses the chunks from the OP pool in a first-come, first-served order to provide the logical block size granularity. However, the present invention is not limited thereto. For example, in one or more embodiments, when the controller of the storage device uses the chunks of the OP pool as unaligned chunks, it considers several factors such as the size of the namespace, the number of chunks available in the OP pool, the format of the namespace (e.g., whether to provide metadata supporting the logical block size and / or end-to-end protection), shared versus private designation, the potential amount of capacity loss, the number of namespaces supported, and others.

[0040] Accordingly, a system and method are provided that reduce capacity loss associated with namespace generation by using chunks of an OP pool as unaligned chunks based on a set (e.g., predetermined) logic.

[0041] FIG. 1 is a diagram showing a system according to one or more embodiments of the present invention.

[0042] Referring to FIG. 1, the system includes a host 102 and a storage device 104. In one or more embodiments, the host 102 is housed (e.g., integrated) with the storage device 104, and in other embodiments, the host 102 is separated from the storage device 104.

[0043] The host 102 may include a processor such as a central processing unit (CPU) and host memory. The storage device 104 includes a controller 108 (e.g., a storage controller or an SSD controller) and a memory 106. In one or more embodiments, the memory includes one or more flash memory cells. For example, the storage device 104 is a solid state storage device (SSD), and the memory is NAND 106 (e.g., a plurality of NAND memory cells) coupled to the controller 108.

[0044] In one or more embodiments, the host 102 communicates with the storage device 104 via a PCIe (Peripheral Component Interconnect Express) interface (e.g., a PCIe bus). However, the present invention is not limited thereto. For example, the host 102 communicates with the storage device 104 via an Ethernet (registered trademark) bus, NVMe over fabric, or any other suitable bus known to those skilled in the art.

[0045] In one or more embodiments, the controller 108 of the storage device 104 includes a processor 110, such as a CPU, and an internal memory 112 (e.g., DRAM, SRAM, flash memory, etc.). Logic stored in the internal memory 112 (e.g., DRAM) and / or firmware (e.g., ASIC or FPGA) is used or executed by the processor 110 to perform one or more processes or process modules described herein, such as the functions of the host interface layer (HIL) 114 and the flash translation layer (FTL) 116. The HIL 114 of the controller 108 is configured to communicate with the host 102, and the FTL 116 of the controller 108 is configured to provide or map the logical page number (LPN) converted from the logical block address (LBA) by the HIL 114 to a physical address within the NAND 106 of the storage device 104.

[0046] In one or more embodiments, the HIL 114 receives commands and / or data from the host 102. The host 102 requests from the HIL 114 attributes of the existing namespace, the total capacity of the visible chunks, the capacity available for namespace allocation, the chunk size, the total number of supported namespaces, etc., in order to provide information to the user. In response, the HIL 114 of the controller 108 of the storage device 104 transfers or provides attributes of the existing namespace, the total capacity of the visible chunks, the capacity available for namespace allocation, the chunk size, the total number of supported namespaces, and / or the like.

[0047] However, in one or more embodiments, the HIL 114 maintains a pool of hidden chunks from the OP pool, and the HIL 114 hides the hidden chunks from the host 102. That is, the HIL 114 has a visible chunk pool and a hidden chunk pool such that the HIL 114 reports the attributes of the visible chunk pool in response to requests (e.g., requests for information) from the host 102, and does not report the attributes of the hidden chunk pool to the host 102 in response to requests (e.g., requests for information) from the host 102.

[0048] In one or more embodiments, when a user generates or requests a new namespace, host 102 enables the user to select the size, format, etc. of the namespace. The size of the namespace is the same as one or more logical blocks, and one logical block is the minimum unit for NVMe specification I / O commands (e.g., read and write commands) for data addressing. The logical block size is selectively set in the format of the namespace. Thus, the logical block size can be different for different namespaces according to the requests of the user and / or host 102. As an example, host 102 sets the logical block size to any appropriate value, such as 512 bytes or 4KB, in the format of the namespace. Host 102 addresses different logical blocks associated with the namespace using LBAs. That is, each logical block of the namespace corresponds to a different LBA within the LBA range.

[0049] Host 102 sends a command to HIL114 to generate a namespace that includes the LBA range associated with the namespace. HIL114 configures or maps the LBA to the LPN of storage device 104. That is, HIL114 converts the LBA from host 102 to the LPN of storage device 104. The LPN of HIL114 is used to communicate with or send requests to FTL116 such that FTL116 maps or converts the LPN to the corresponding physical address of NAND106.

[0050] Although a specific approach for mapping in HIL114 and FTL116 has been described, any appropriate approach for mapping known to those skilled in the art can be used with appropriate adaptations thereto.

[0051] In one or more embodiments, the chunks associated with a chunk entry (CE) are referenced by a plurality of LBAs from the perspective of host 102 and / or by a plurality of LPNs (i.e., an LPN range) from the perspective of controller 108 of storage device 104. Since the size of the logical blocks associated with the LBA range requested from the host may not match the size of the chunks, the host may not be divisible by a multiple of one chunk size or may request a plurality of logical blocks corresponding to the total size that is a multiple of one chunk size. That is, the total size of the logical blocks requested by the host does not match (e.g., exactly or precisely match) the total size of one or more chunks used or requested to support all the logical blocks requested by the host. Therefore, host 102 may not be divisible by a multiple of one chunk size or may request a plurality of logical blocks corresponding to the total size that is a multiple of one chunk size. In this case, storage device 104 rounds up the number of chunks used to provide sufficient capacity for the namespace requested by host 102. The rounding error is the same as the capacity loss associated with generating the namespace because the addressing becomes impossible after the namespace is used. As a result, one chunk used in the namespace (e.g., the chunk that is rounded up) is an unaligned chunk (i.e., a chunk that after generating the namespace, some addresses cannot be specified and capacity loss may occur).

[0052] In one or more embodiments, the chunk size is based on the capacity of the NAND 106 and the number of chunk entries supported by the hardware of the storage device 104. For example, the chunk size is the same as the capacity of the NAND 106 divided by the number of chunk entries. In a non-limiting example, 2000 chunk entries are supported and the capacity of the NAND 106 (e.g., the capacity of the drive) is 2 TB (terabytes). In this case, since the value obtained by dividing 2 TB by 2000 is 1 GB, the storage device 104 provides a chunk size of 1 GB. Thus, in this case, each chunk entry means a chunk (or LPN range) containing 1 GB. However, the present invention is not limited to this, and any chunk size can be used depending on the number of chunk entries supported by the hardware of the storage device 104 and the size of the NAND 106 (i.e., the total drive capacity). For example, the hardware of the storage device supports 2048 chunk entries and the storage device 104 has a drive capacity of 32 TB. In this case, a chunk size of 15.625 GB is provided by the storage device 104.

[0053] FIG. 2A is a block diagram showing an example of management of a first-come, first-served-based namespace according to one or more embodiments of the present invention. FIG. 2B is a block diagram showing an example of management of a namespace based on capacity loss according to one or more embodiments of the present invention. FIG. 2C is a block diagram showing an example of management of a namespace based on the size of the namespace according to one or more embodiments of the present invention.

[0054] Referring to FIGS. 1 and 2A-2C, the interaction between host 102 and storage device 104 is shown, for convenience, based on chunk entries (CEs). Each CE corresponds to a range of LBAs from the perspective of host 102 and a range of LPNs from the perspective of controller 108. Since the size of the logical blocks associated with the LBA range requested from the host may not match (e.g., precisely or exactly match) the chunk size, the host may request to divide by a multiple of one chunk size or request multiple logical blocks corresponding to the total size that is a multiple of one chunk size. Thus, the total size of the logical blocks requested for the namespace may not be aligned (i.e., may not be the same) with one or more of the chunk sizes used for the namespace. As such, unaligned chunks (i.e., chunks that can only be addressed partially by the namespace) are used by the controller of the storage device as part of the unaligned chunk that cannot be addressed, as shown in FIGS. 2A-2C. In the illustrated embodiment, unaligned chunks are designated, for convenience, as "UC" and are hereinafter referred to as UCs. Note that hidden chunks that are hidden from or not reported by host 102 are designated, for convenience, as hidden chunk "HC".

[0055] In the comparative example, the HIL includes a visible chunk pool and does not include a hidden chunk pool. Thus, the HIL provides (or advertises) the full capacity of the HIL to the host. In this case, the FTL including chunks corresponding to the OP pool and chunks separated from the OP pool reports only the chunks separated from the OP pool to the HIL and hides the chunks of the OP pool from the HIL. That is, all chunks of the HIL are visible to the host, and the chunks from the OP pool are not reported to the HIL by the FTL.

[0056] However, as shown in FIGS. 1 and 2A-2C, in one or more embodiments of the present invention, FTL 116 reports chunks separated from OP pool 202 to HIL 114 and reports one or more chunks of OP pool 202 to HIL 114. Thus, chunks from OP pool 202 that are reported to HIL 114 by FTL 116 but hidden from host 102 by HIL 114 are HCs. For example, as shown in FIGS. 2A-2C, all chunks of OP pool 202 reported to HIL 114 are hidden from host 102, and thus are HCs.

[0057] As shown in FIG. 2A, UC is absorbed by HCs from OP pool 202 in a first-come, first-served manner by using HCs from OP pool 202 as UCs in a first-come, first-served manner. For example, when a UC is formed in response to a name space generation request of host 102, chunks of OP pool 202 are used as UCs from among the HCs of HIL 114. If the UC is not formed in response to a request from host 102 to generate a name space, applying a logical block size granularity instead of a chunk size granularity cannot save capacity (for example, save capacity by avoiding capacity loss), so chunks from OP pool 202 are not used. Therefore, one or more chunks of OP pool 202 that are HCs are stored for subsequent name space generation requests for which a logical block size granularity is preferred.

[0058] In one or more embodiments, chunks from OP pool 202 are suitable for use as UCs because the chunks from OP pool 202 are in an unmapped area (i.e., an unmapped area of NAND 106). Thus, the use of chunks from OP pool 202 does not result in loss of OP pool 202. That is, for example, operations performed by OP pool 202, such as wear leveling, garbage collection, and / or others, are not affected by chunks from OP pool 202 used as UCs.

[0059] In the illustrated embodiment, host 102 requests the generation of a first namespace 204 and a second namespace 206 from among the unused chunks 208 reported to host 102 from the visible chunk pool of HIL 114. This is because for each of the first namespace 204 and the second namespace 206, the total size of the logical blocks requested by host 102 cannot be divided by a multiple of one chunk size or is a multiple of one chunk size, as shown in FIGS. 2A - 2C, and each of the first namespace 204 and the second namespace 206 is an unaligned namespace where the first namespace 204 includes UC and the second namespace 206 includes UC. Depending on the chunk size granularity, a portion of the UC of each of the first namespace 204 and the second namespace 206 becomes unaddressable, resulting in a loss of capacity. Therefore, to avoid loss of capacity, the HC of HIL 114 (e.g., the HC from the OP pool 202) is used as the UC associated with the first namespace 204 and the second namespace 206 so that the logical block size granularity is provided to the first namespace 204 and the second namespace 206 on a first-come, first-serve basis.

[0060] In one or more embodiments, the use of the HC as shown in FIGS. 2A - 2C prevents or substantially prevents the host from recognizing a change in the available capacity of the host in order to show that the logical block size granularity is provided for a namespace in which the UC is absorbed by the OP pool 202 (i.e., the HC of the OP pool 202 is used as the UC). Thus, the visible chunks that cannot be addressed in other ways and that cause a visible capacity loss remain as unused for subsequent namespace requests and are visible and available to host 102. That is, the host does not receive an indication of the loss of capacity. Therefore, storage device 104 reports to the host that there is no loss of capacity due to unaligned chunks by utilizing the HC.

[0061] In one or more embodiments, as shown in FIGS. 1 and 2B-2C, the visible chunks of HIL 114 separated from the chunks from the OP pool 202 are used for the UC of the namespace based on a (e.g., preset) setting logic, as will be described in more detail below. In this case, the UC causes a capacity loss related to the generation of the namespace, and chunks that cannot be partially addressed occur. Thus, chunk size granularity is provided for the namespace, and due to the generation of the namespace, the host 102 recognizes a corresponding capacity loss. This is because the visible chunks used as the UC are not used for subsequent namespaces.

[0062] In one or more embodiments, for the HIL 114 used as the UC, the chunks from the OP pool 202 reported by the FTL 116 are fewer than the total number of namespaces supported by the controller 108 of the storage device 104. For example, different NAND types, such as TLC (Triple-Level Cell Flash), QLC (Quad-Level Cell Flash), and Z-NAND, support different numbers of namespaces. The FTL 116 uses the internal memory 112 (e.g., DRAM) to support a set number of chunks from the OP pool 202 used as the HC, and the set number of chunks of the OP pool 202 used for the UC depends on the amount of available internal memory. For example, increasing the number of chunks of the OP pool used as the HC increases the amount of internal memory 112 (e.g., DRAM) used. Thus, in one or more embodiments, depending on the type of the NAND 106 of the storage device 104 and the amount of available internal memory 112 of the controller 108, the total number of namespaces supported by the controller 108 is more than the set number of chunks from the OP pool 202 used as the UC supported by the controller 108.

[0063] In one or more embodiments, the systems and methods of the present invention include build-time customizable features based on NAND type and appropriate product variants. Thus, a host is connected to a plurality of storage devices having the same or different NAND types (i.e., hybrid drive types), and the host sends requests to one or more connected storage devices as desired to allocate one or more namespaces.

[0064] By way of non-limiting example, the controller 108 of the storage device 104 supports, for example, the generation of up to 64 visible chunks or up to 64 namespaces corresponding to CEs (e.g., depending on the NAND type). Thus, the total capacity for generating 64 namespaces multiplied by the chunk size (i.e., the size of the chunk corresponding to the CE) is provided. In this case, for example, the controller 108 of the storage device 104 supports 32 chunks (e.g., depending on the internal memory 112 or DRAM) from the OP pool 202 used as the HC. Depending on the size of the namespace requested by the host 102, the host 102 requests the generation of more than 32 namespaces (e.g., between 33 and 64 namespaces). If the first-come, first-served method is applied and more than 32 UCs exist simultaneously, since the chunks of the OP pool 202 cannot be used as the 33rd UC, using a visible chunk separated from the OP pool 202 as the 33rd UC will result in a capacity loss.

[0065] A specific number for the namespaces and chunks of the OP pool used as the UC is provided, but the present invention is not limited thereto, and any suitable number may be used based on hardware and / or software constraints.

[0066] Although first-come, first-served is provided with reference to FIG. 2A, the present invention is not limited thereto. In one or more embodiments, when using chunks from the OP pool 202 used as the UC, any other suitable logical arrangement is considered.

[0067] For example, as shown in FIG. 2B, for each of the first namespace 204 and the second namespace 206, the total size of the logical blocks requested by the host 102 cannot be divided by a multiple of one chunk size or becomes a multiple of one chunk size. Thus, each of the first namespace 204 and the second namespace 206 is an unaligned namespace where the first namespace 204 contains UC and the second namespace 206 contains UC. Depending on the chunk size granularity, a portion of the UC in each of the first namespace 204 and the second namespace 206 becomes unaddressable, resulting in a loss of capacity. The amount of unaddressable memory formed according to the chunk size granularity is used as a factor to determine whether the HC from the OP pool 202 is used to provide logical block size granularity. At this time, if more memory than the amount set due to UC is not addressed (i.e., if the capacity loss exceeds the set amount), a threshold is used, and subsequently, the HC of the OP pool 202 is used to provide logical block size granularity (assuming the HC of the OP pool 202 is available). Thus, as shown in FIG. 2B, the UC of the first namespace 204 that forms unaddressable memory less than the threshold uses the chunks of the visible chunk pool of the HIL 114, resulting in a small loss of capacity (i.e., the chunks from the visible chunk pool of the HIL 114 are used as the UC of the first namespace 204). On the other hand, as shown in FIG. 2B, the UC of the second namespace 206, which is potentially associated with a larger loss of capacity than the UC of the first namespace 204, exceeds the threshold and thus uses the HC of the OP pool 202 to obtain logical block size granularity (i.e., the HC of the OP pool 202 is used as the UC of the second namespace 206), potentially preventing a larger loss of capacity.

[0068] As another example, as shown in FIG. 2C, the size of the namespace is used as a factor to determine whether the HC from the OP pool 202 should be used to provide logical block size granularity. In this case, using the HC from the OP pool 202 is based on the required size of the namespace. For example, the threshold is to apply HC to unaligned chunks where the size of the namespace is less than one chunk. Thus, as shown in FIG. 2C, the first namespace 204 that is larger than one chunk and has UC forms unaddressable memory that results in a loss of capacity. However, the second namespace 206 that is smaller than one chunk and has UC uses the HC from the OP pool 202 to obtain logical block size granularity and prevent the corresponding loss of capacity.

[0069] A number of arrays are described separately with reference to FIGS. 2A-2C, but the logical arrays according to one or more embodiments are based on combinations of the arrays shown in FIGS. 2A-2C.

[0070] In one or more embodiments, when one or more logical arrays are implemented based on one or more thresholds, a threshold or multiple-threshold approach is used. For example, the unused capacity of the NAND 106 is used to determine whether to provide logical block size granularity, and in such a case, it is used to determine which of one or more logical arrays for applying the logical block size granularity should be applied. That is, a system and method for providing logical block size granularity are provided when the unused capacity for the namespace is less than or exceeds a set threshold. In a non-limiting example, the logical block size granularity is provided on a first-come, first-served basis when less than 20% of the chunks in the visible pool of the HIL 114 are unused chunks 208.

[0071] In one or more embodiments, a dynamic approach (as opposed to a static approach) is used to determine the use of chunks from the OP pool 202 as UCs. For example, in one or more embodiments, the controller 108 dynamically adjusts whether the HC of the OP pool 202 is used as a UC in real time or at set time intervals (e.g., when a namespace request is received) based on the priority of the namespace including the UC. In a non-limiting example, the HCs from the OP pool 202 are used on a first-come, first-served basis until all HCs are used as UCs corresponding to the UCs of their respective private namespaces. As additional namespaces including UCs are requested, the controller 108 determines the priority associated with each of the namespaces including the UC. For example, the controller 108 determines that using a chunk from the OP pool 202 as one UC potentially results in less capacity loss than using a chunk from the OP pool 202 as another UC associated with another namespace. In this case, the namespace that results in less capacity loss has a lower priority than the priority of the namespace that results in more capacity loss.

[0072] Accordingly, even if all HCs in the OP pool 202 in HIL114 are used, the controller 108 changes the HCs used as UCs in the lower-priority namespace and makes them be used as UCs in the higher-priority namespace, thereby reducing potential capacity loss. If the namespace containing the UC has a lower priority than all the namespaces in which the chunks of the OP pool are used, no change occurs. Before making the change, the controller 108 uses the chunks of NAND 106 separated from the OP pool 202 (e.g., the memory chunks of the visible chunk pool) in HIL114 to accommodate the memory in the lower-priority namespace that may have been previously absorbed by the HCs from the OP pool 202. That is, the data previously absorbed by the HCs from the OP pool 202 is copied to the chunks of NAND 106 separated from the OP pool 202 before using the HCs from the OP pool 202 as UCs in the higher-priority namespace. Accordingly, the lower-priority namespace is changed from the logical block size granularity to the chunk size granularity, and the higher-priority namespace is provided with the logical block size granularity instead of the chunk size granularity based on priority. In one or more embodiments, the priority is based on factors and / or the attributes of the namespace described in more detail below, as described with reference to FIGS. 2A-2C.

[0073] An array based on first-come, first-served order, the size of the namespace, and / or potential capacity loss has been described, but the present invention is not limited thereto. For example, the attributes of the namespace are used alone or in combination with respect to the arrays described with reference to FIGS. 2A-2C.

[0074] FIG. 3A is a diagram showing a system according to one or more embodiments of the present invention. FIG. 3B is a block diagram showing shared and private namespaces according to one or more embodiments of the present invention.

[0075] Referring to FIG. 3A, the system includes a first or second controller (108a, 108b) of the storage device 104 and one or more hosts (e.g., a first host 302 and a second host 304) that communicate (e.g., via two separate ports corresponding to the PCIe links of the first host 302 and the PCIe links of the second host 304, each connected to two separate ports) with the first and second controllers (108a, 108b). As an example, in the system shown in FIG. 3A, the first and second controllers (108a, 108b) are connected to separate hosts (302, 304), but the NAND 106 and the FTL 116 are not divided by the two separate ports and the first and second controllers (108a, 108b). Note that in one or more embodiments, the processor 110, the internal memory 112, and the HIL 114 are not divided by the two separate ports and the first and second controllers (108a, 108b).

[0076] In one or more embodiments, the first host 302 and the second host 304 execute programs in software to generate a first virtual machine 306 and a second virtual machine 308, respectively. The first virtual machine 306 and the second virtual machine 308 emulate the functionality of a computing environment. In one or more embodiments, the first controller 108a and / or the second controller 108b provide a first virtual function 305 and a second virtual function 307 for use as connections to the first virtual machine 306 and the second virtual machine 308, respectively, to manage their respective namespaces. Thus, the storage device 104 includes both a physical connection (e.g., via a PCIe link) and a virtual connection (e.g., via virtualization) to the first host 302 and / or the second host 304 to manage a namespace (e.g., a namespace with shared attributes).

[0077] As shown in FIG. 3A, storage device 104 includes a processor 110 such as a CPU and an internal memory 112 (e.g., DRAM, SRAM, flash memory, etc.). Logic stored in internal memory 112 (e.g., DRAM), and / or firmware (e.g., ASIC or FPGA) is used or executed by processor 110 to perform one or more processes or process modules described herein, such as the functions of HIL 114, the functions of FTL 116, the first virtual function 305, and the second virtual function 307. Processor 110 and internal memory 112 are one or more processors and / or one or more memory devices that operate alone or in combination with each other, and are components of the first controller 108a, the second controller 108b, and / or any other controller of the storage device.

[0078] In one or more embodiments, the first and second hosts (302, 304) send requests to generate the first namespace 312, the second namespace 314, and the third namespace 310 with attributes set via corresponding physical connections. In one or more embodiments, the first and second virtual machines (306, 308) send requests to generate the first namespace 312, the second namespace 314, and the third namespace 310 with attributes set via virtual connections.

[0079] As shown in FIG. 3B, the first namespace 312 and the third namespace 310 are designated as private namespaces, and the second namespace 314 is designated as a shared namespace between the first virtual machine 306 and the second virtual machine 308 using communications transferred via virtual connections. However, the present invention is not limited to this. In one or more embodiments, the first namespace 312 and the third namespace 310 are designated as private namespaces, and the second namespace 314 is designated as a shared namespace between the first host 302 and the second host 304 using communications transferred via physical connections.

[0080] In the physical case, the first controller 108a reports information to the first host 302 such that the first host 302 receives information from the HIL 114 and sends commands to the HIL 114 associated with the second namespace 314 and the first namespace 312. In one or more embodiments, the second controller 108b reports information to the second host 304 such that the second host 304 receives information from the HIL 114 and sends commands to the HIL 114 associated with the second namespace 314 and the third namespace 310.

[0081] In the virtual case, the first virtual function 305 of the storage device 104 reports information to the first virtual machine 306 such that the first virtual machine 306 receives information from the first virtual function 305 and sends commands to the first virtual function 305 associated with the second namespace 314 and the first namespace 312. In one or more embodiments, the second virtual function 307 of the storage device 104 reports information to the second virtual machine 308 such that the second virtual machine 308 receives information from the second virtual function 307 and sends commands to the second virtual function 307 associated with the second namespace 314 and the third namespace 310.

[0082] FIG. 3C is a block diagram showing an example of namespace management according to one or more embodiments of the present invention.

[0083] Referring to FIG. 3C, the shared and private designations are used as factors to determine whether the HCs from the OP pool 316 should be used to provide logical block size granularity. In this case, the HCs from the OP pool 316 are used for a shared namespace that includes UCs to absorb the UCs, and the HCs from the OP pool 316 are not used for a private namespace that includes UCs. For example, as shown in FIG. 3C, since the first namespace 312 that includes UCs is private, the HCs from the OP pool 316 are not used as UCs. As a result, a chunk of memory separated from the OP pool 316 is used, resulting in a loss of capacity. In the illustrated embodiment, the second namespace 314 that includes UCs is shared, and thus the HCs from the OP pool 316 are used as UCs (e.g., by providing logical block size granularity) to avoid loss of capacity.

[0084] As an example for determining whether to apply logical block size granularity, a shared namespace and a private namespace are used, but the designations of the shared namespace and the private namespace are examples of the attributes of the available namespaces, so the present invention is not limited thereto. In other embodiments, any suitable attribute of the namespace (e.g., the format of the namespace such as whether metadata supporting logical block size and / or end-to-end protection is provided, the group number associated with the namespace, the privacy designation, the logical block size, etc.) is used alone or in combination with other attributes. In one or more embodiments, the attributes of the namespace are used alone or in combination with other factors such as first-come-first-served order, the size of the namespace, and / or potential loss of capacity.

[0085] FIG. 4A is a flowchart of a method for managing a static namespace according to one or more embodiments of the present invention.

[0086] Referring to FIG. 4A, a system and method for managing a static namespace includes a controller 108 of a storage device 104 that uses NAND 106 of the storage device to allocate a namespace in response to a request from a host 102 (see, for example, FIG. 1). As will be described with reference to FIGS. 2A-2C and 3C, the controller 108 selectively uses chunks from an OP pool (202, 316) as UCs to provide a logical block size granularity for the namespace.

[0087] In one or more embodiments, the method includes a step 402 of receiving a request from the host 102 to allocate a namespace. The host 102 specifies attributes of the namespace when sending a request to the controller 108 to allocate a namespace.

[0088] In one or more embodiments, the controller 108 applies a management policy of the namespace to determine whether to use chunks from an OP pool (202, 316) as UCs (step 404). For example, the controller 108 determines whether the namespace includes a UC. If the namespace does not include a UC (step 405), the controller 108 allocates the namespace without using chunks from the OP pool (202, 316) (step 406). However, if the namespace includes a UC, the controller 108 determines whether one or more conditions for applying the logical block size granularity are met.

[0089] For example, the controller 108 checks whether it has a chunk (e.g., an HC) from an OP pool (202, 316) in which the HIL 114 of the controller 108 is used as a UC. If the chunks of the OP pool (202, 316) are not used as UCs (step 405), the controller 108 allocates the namespace without using the chunks of the OP pool that would result in a loss of capacity due to the UC (step 406). If the chunks are available in the OP pool (202, 316) for use by the HIL 114, the controller 108 considers one or more additional factors to determine whether to use the chunks from the OP pool (202, 316) as UCs.

[0090] Although the availability of chunks from the OP pool (202, 316) has been described as a condition for applying the logical block size granularity, the present invention is not limited thereto. For example, one or more conditions include the availability of chunks from the OP pool (202, 316) such as whether the capacity for the NAND 106 of the namespace is higher or lower than a set threshold.

[0091] In one or more embodiments, one or more additional factors considered by the namespace management policy (stage 404) to determine whether to use chunks from the OP pool (202, 316) as the UC of the namespace are discussed throughout the present invention and are, for example, any of the factors shown in stage 404 of FIG. 4A. For example, the namespace management policy operates in a first-come, first-served manner or operates based on potential capacity loss, namespace size, namespace format, privacy designation, namespace group number, other attributes of the namespace, or combinations thereof.

[0092] If one or more conditions are not met (stage 405), the controller 108 allocates the namespace (stage 406) without using chunks from the OP pool (202, 316) that would result in capacity loss due to the UC. That is, the namespace is provided with chunk size granularity. When all factors are met (stage 405), the controller uses chunks from the OP pool (202, 316) as the UC and uses one or more chunks separated from the OP pool (202, 316) for any other requirements of the namespace (e.g., additional chunks) (stage 408). By using chunks from the OP pool (202, 316) as the UC, the logical block size granularity is provided for the namespace.

[0093] FIG. 4B is a flowchart of a method for managing a dynamic namespace according to one or more embodiments of the present invention.

[0094] Referring to FIG. 4B, a system and method for managing a dynamic namespace includes a controller 108 of a storage device 104 that uses NAND 106 of the storage device to allocate a namespace in response to a request from a host 102 (see, e.g., FIG. 1). As described with reference to FIGS. 2A-2C and 3C, the controller 108 selectively uses chunks from an OP pool (202, 316) as UCs to provide a logical block size granularity for the namespace.

[0095] In one or more embodiments, the method includes a step 402 of receiving a request from the host 102 to allocate a namespace. The host 102 specifies the attributes of the namespace when sending a request to the controller 108 to allocate a namespace. In one or more embodiments, the controller 108 applies a namespace management policy to determine whether to use chunks from the OP pool (202, 316) as UCs (step 404). For example, the controller 108 determines whether the namespace includes a UC. If the namespace does not include a UC (step 405), the controller 108 allocates the namespace without using chunks from the OP pool (step 406).

[0096] In one or more embodiments, the namespace management policy considers one or more additional factors to determine whether to use chunks from the OP pool (202, 316) as UCs for the namespace. The one or more additional factors are discussed throughout the present invention and are, for example, any of the factors illustrated in step 404 of FIG. 4B. For example, the namespace management policy operates in a first-come, first-served manner or operates based on loss of capacity, namespace size, namespace format, privacy designation, namespace group number, other attributes of the namespace, or combinations thereof.

[0097] If one or more conditions are not met (step 405), the controller 108 allocates a namespace without using chunks from the OP pool (202, 316) that would result in capacity loss by the UC. That is, the namespace is provided at the chunk size granularity. If all factors are met (step 405) and chunks from the OP pool (202, 316) can be used as the UC (step 407), the controller uses chunks from the OP pool (202, 316) as the UC and uses one or more chunks separated from the OP pool (202, 316) for any other requirements of the namespace (e.g., additional chunks) (step 408). By using chunks from the OP pool (202, 316) as the UC, the logical block size granularity is provided for the namespace.

[0098] However, if the chunks of the OP pool (202, 316) are not used as UCs (stage 407), the controller 108 considers the namespace priority in comparison with the priority of the existing namespace that includes a UC in which the chunks of the OP pool (202, 316) are used as the UC of the existing namespace (stage 410). For example, according to the factors of the namespace management policy at stage 404, the controller 108 determines that the new namespace is more suitable (e.g., has a higher priority) than the existing namespace (e.g., a namespace with a lower priority) in which the chunks of the OP pool (202, 316) are used as UCs for the logical block size granularity (stage 410). If the new namespace has a higher priority than the existing namespace, the controller 108 copies the chunk data of the OP pool (202, 316) used in the namespace with the lower priority to an unused chunk separate from the OP pool (202, 316) (stage 412). Accordingly, a capacity loss related to the namespace with the lower priority occurs. That is, the data previously absorbed by the chunks of the OP pool (202, 316) is copied to the NAND 106 chunks separate from the OP pool 202 of the namespace with the lower priority. Note that the controller 108 uses the currently available chunks (e.g., the copied chunks) from the OP pool (202, 316) of the namespace with the higher priority as UCs and uses one or more chunks separated from the OP pool (202, 316) for any other requests of the namespace with the higher priority (stage 414). In this way, the namespace with the higher priority is provided at the logical block size granularity even though all the chunks of the OP pool (202, 316) are used as UCs (e.g., used all at once or simultaneously), while the namespace with the lower priority is changed from the logical block size granularity to the chunk size granularity. Accordingly, the dynamic approach enables the controller 108 to adaptively accommodate the namespace requests even though all the chunks from the OP pool (202, 316) are used as UCs (e.g., used all at once or simultaneously) in the HIL 114 of the controller 108.

[0099] In one or more embodiments, the controller 108 compares the priority of the new namespace to each existing namespace to determine or identify an existing namespace (if any) that is being changed from logical block size granularity to chunk size granularity, as described in steps 410, 412, and 414. That is, in a non-limiting example, the new namespace has a higher priority than one or more existing namespaces, and the controller 108 selects the namespace with the lowest priority to change from logical block size granularity to chunk size granularity.

[0100] If the new namespace has a lower priority than all existing namespaces (step 410), the controller 108 allocates the namespace without using the chunks of the OP pool that would result in a loss of capacity by the UC (step 406).

[0101] Accordingly, as disclosed herein, embodiments of the present invention provide a namespace management system and method for providing logical block size granularity. The system and method of one or more embodiments of the present invention provide logic for static and dynamic adjustment of a namespace that provides logical block size granularity based on one or more of the factors described herein.

[0102] In the drawings, the relative sizes of components, layers, and regions are exaggerated and / or simplified for clarity.

[0103] Merely, terms such as "first", "second", "third", etc. are used in this specification to describe various components, elements, regions, layers, and / or sections, but these components, elements, regions, layers, and / or sections are not limited by these terms. These terms are used to distinguish one component, element, region, layer, or section from other components, elements, regions, layers, or sections. Thus, a first component, element, region, layer, or section refers to a second component, element, region, layer, or section without departing from the technical idea and scope of the present invention.

[0104] When a component or layer is described as being "on", "connected to", or "coupled to" another component or layer, it is understood that it is either directly disposed, directly connected, or directly coupled to the other component or layer, or that one or more intervening components or layers are present. When a component or layer is described as being "between" two components or layers, it is either the only component or the only layer between the two components or layers, or one or more intervening components or layers are present.

[0105] The terms used in this specification are for the purpose of merely describing particular embodiments and are not intended to limit the present invention. As used in this specification, unless it is determined otherwise from the context that it clearly indicates a different meaning, the singular form also includes the plural forms. When the terms "comprise", "comprising", "have", and "having" are used in this specification, these terms indicate the presence of the defined features, integers, steps, operations, components, and / or elements, but do not exclude the addition or presence of one or more other features, integers, steps, operations, components, elements, and / or groups thereof. The term "and / or" used in this specification includes any and all combinations associated with one or more of the listed items. Expressions such as "at least one", when coming before a list of components, modify the entire list of components and not the individual elements of the list.

[0106] When describing the embodiments of the present invention, the term "can" means "one or more embodiments of the present invention". The terms "use", "using", and "used" as used in this specification are synonymous with the terms "utilize", "utilizing", and "utilized", respectively.

[0107] The terms "substantially", "about", and similar terms used in this specification are used as terms of approximation rather than terms of degree to account for the inherent deviations of measured or calculated values recognized by a person of ordinary skill in the art.

[0108] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. These terms as used in the general context of a dictionary definition are to be interpreted as having a meaning consistent with the context of the relevant art and / or this specification, and are not to be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0109] Embodiments of the present invention have been specifically illustrated and described with reference to the drawings. However, the specific terms used herein are for the purpose of describing the present invention only and are not intended to define or limit the technical scope of the present invention. Therefore, it is understood by those of ordinary skill in the art to which this invention belongs that various modifications and other equivalent embodiments of the present invention are possible.

Description of Reference Numerals

[0110] 102 Host 104 Storage Device 106 Memory (NAND) 108 Controller 108a First Controller 108b Second Controller 110 Processor 112 Internal Memory 114 Host Interface Layer (HIL) 116 Flash Translation Layer (FTL) 202, 316 OP Pool 204 First Namespace 206 Second Namespace 208 Chunk 302 First Host 304 Second Host 305 First Virtual Function 306 First Virtual Machine 307 Second Virtual Function 308 Second Virtual Machine 310 Third Namespace 312 First name space 314 Second name space

Claims

1. A storage device configured to support a plurality of namespaces, comprising: a memory; a controller coupled to the memory, wherein the controller includes an internal memory and a host interface layer, and a flash translation layer configured to report to the host interface layer a first over-provisioning chunk from an over-provisioning pool and a first chunk separate from the over-provisioning pool; the controller is configured to receive a command at the host interface layer and utilize a portion of the memory for a first namespace from among the plurality of namespaces, the first namespace including unaligned chunks; the controller is configured to utilize the first over-provisioning chunk as the unaligned chunk of the first namespace; the number of over-provisioning chunks utilized as unaligned chunks is less than the number of the plurality of namespaces; A storage device, wherein the number of over-provisioning chunks utilized as unaligned chunks is based on an amount of the internal memory of the controller.

2. The storage device according to claim 1, wherein a type of the memory of the storage device is a triple-level cell flash, a quad-level cell flash, or a Z-NAND type, and the number of the plurality of namespaces is based on the type of the memory.

3. The host interface layer includes a visible chunk pool including the first chunk and a hidden chunk pool including the first over-provisioning chunk, and is configured to report information about the visible chunk pool to a host and hide information about the hidden chunk pool from the host; The storage device according to claim 1, wherein the host is configured to send the command to the storage device to utilize the portion of the memory for the first namespace from among the plurality of namespaces.

4. The storage device according to claim 1, wherein the controller is further configured to use the first over-provisioning chunk for the first namespace in a first-come, first-served order.

5. The storage device according to claim 1, wherein the controller is further configured to use the first over-provisioning chunk based on a privacy designation, formatting, or group number of the first namespace.

6. The storage device according to claim 1, wherein the controller is further configured to use the first over-provisioning chunk when a potential capacity loss amount of the first namespace associated with the first namespace exceeds a set threshold value.

7. The storage device according to claim 1, wherein the controller is further configured to use the first over-provisioning chunk when a size of the first namespace is smaller than a set threshold value.

8. A system comprising: the storage device according to claim 1; and a host configured to send the command to the storage device to use a part of the memory for the first namespace from among the plurality of namespaces.

9. A method for managing a namespace in a storage device, comprising: supporting a plurality of namespaces by the storage device; reporting, by a flash translation layer of a controller of the storage device, a first over-provisioning chunk from an over-provisioning pool and a first chunk separate from the over-provisioning pool to a host interface layer of the controller of the storage device; receiving, by the storage device, a command at the host interface layer to use a part of the memory for a first namespace from among the plurality of namespaces, the first namespace including unaligned chunks; and using, by the controller, the first over-provisioning chunk as the unaligned chunk of the first namespace. The step of supporting, by the controller, the number of over-provisioning chunks used as unaligned chunks, wherein the number of over-provisioning chunks is based on the amount of internal memory of the controller, and A method characterized in that the number of over-provisioning chunks used as unaligned chunks is less than the number of the plurality of namespaces. **Claim 10** The method according to claim 9, further comprising the step of supporting the plurality of namespaces based on the type of the memory of the storage device, wherein the type of the memory is a triple-level cell flash, a quad-level cell flash, or a Z-NAND type. **Claim 11** The step of reporting, by the host interface layer, information about the visible chunk pool including the first chunk to the host; The step of hiding, by the host interface layer, information about the hidden chunk pool including the first over-provisioning chunk from the host; The method according to claim 9, further comprising the step of sending, by the host, the command to the storage device to use the part of the memory for the first namespace from among the plurality of namespaces. **Claim 12** The method according to claim 9, further comprising the step of using, by the controller, the first over-provisioning chunk for the first namespace in a first-come-first-served order. **Claim 13** The method according to claim 9, further comprising the step of using, by the controller, the first over-provisioning chunk based on the privacy designation, format, or group number of the first namespace. **Claim 14** The method according to claim 9, further comprising the step of using, by the controller, the first over-provisioning chunk when the amount of potential capacity loss of the first namespace associated with the first namespace exceeds a set threshold. **Claim 15** The method according to claim 9, further comprising, by the controller, using the first over-provisioning chunk when the size of the first namespace is smaller than a set threshold value.

16. A method for managing a namespace in a storage device including a memory and the controller, wherein the controller includes a host interface layer and a flash translation layer, the method comprising: reporting, by the flash translation layer, a first over-provisioning chunk from an over-provisioning pool and a first chunk separate from the over-provisioning pool to the host interface layer; receiving, by the controller, a first command at the host interface layer and using a first portion of the memory for a first namespace, the first namespace including a first unaligned chunk that is used when a first potential amount of capacity loss associated with the first namespace exceeds a set threshold value; using, by the controller, the first over-provisioning chunk as the first unaligned chunk of the first namespace; receiving, by the controller, a second command at the host interface layer and using a second portion of the memory for a second namespace, the second namespace including a second unaligned chunk; using, by the controller, the first chunk as the second unaligned chunk of the second namespace; supporting, by the controller, a plurality of over-provisioning chunks used as unaligned chunks, the plurality of over-provisioning chunks being based on an amount of internal memory of the controller.

17. The method according to claim 16, further comprising, by the storage device, supporting a plurality of namespaces based on a type of the memory in the storage device, the type of the memory being a triple-level cell flash, a quad-level cell flash, or a Z-NAND type.

18. Reporting information about the visible chunk pool including the first chunk to the host by the host interface layer; Hiding information about the hidden chunk pool including the first over-provisioning chunk from the host by the host interface layer; Sending the first command from the host to the storage device to utilize the first portion of the memory for the first namespace; Sending the second command from the host to the storage device to utilize the first portion of the memory for the second namespace, the method according to claim 16, further comprising.

19. A storage device, A memory, A controller including an internal memory, and The controller, Receives a command to allocate a portion of the memory to a first namespace including unaligned chunks, Compares a potential loss amount of the capacity of the first namespace associated with the first namespace with a set threshold value, and when the potential loss amount of the capacity of the first namespace exceeds the set threshold value, the first over-provisioning chunk from the over-provisioning pool of the internal memory is used as the unaligned chunk of the first namespace. A storage device characterized by being configured as such.

20. The storage device according to claim 19, wherein the controller is further configured to dynamically adjust the first namespace between a logical block size granularity and a chunk size granularity.

21. The type of the memory of the storage device is a triple-level cell flash, a quad-level cell flash, or a Z-NAND type, The number of namespaces supported by the storage device is based on the type of the memory, the storage device according to claim 19.

22. A visible chunk pool including a first chunk, A hidden chunk pool including the first over-provisioning chunk, and The controller is configured to report information about the visible chunk pool to the host and hide information about the hidden chunk pool from the host. The storage device according to claim 19, wherein the host is configured to transmit to the storage device the command for allocating the part of the memory to the first namespace. **Claim 23** The storage device according to claim 19, wherein the controller is further configured to use the first over-provisioning chunk based on a privacy specification. **Claim 24** The storage device according to claim 19, wherein the controller is further configured to use the first over-provisioning chunk based on a group number or format of the first namespace. **Claim 25** A system comprising: the storage device according to claim 19; and a host configured to send the command to the storage device to use the part of the memory in the first namespace. **Claim 26** A storage device comprising: a memory; and a controller including an internal memory, wherein the controller: receives a command for allocating a part of the memory to a first namespace including a first unaligned chunk and a second namespace including a second unaligned chunk; compares a potential capacity loss amount of the first namespace associated with the first namespace with a set threshold value, and when the potential capacity loss amount of the first namespace exceeds the set threshold value, uses a first over-provisioning chunk from an over-provisioning pool of the internal memory as the first unaligned chunk of the first namespace; compares a potential capacity loss amount of the second namespace associated with the second namespace with the set threshold value, and when the potential capacity loss amount of the second namespace is smaller than the set threshold value, is configured to use a first chunk separate from the over-provisioning pool as the second unaligned chunk. **Claim 27** The controller: receives another command for allocating another part of the memory to a third namespace including a third unaligned chunk and having a higher priority than the first namespace. The storage device according to claim 26, further configured to change the first name space from a logical block size granularity to a chunk size granularity.

28. The controller uses the first over-provisioning chunk as the third unaligned chunk The storage device according to claim 27, further configured to use a second chunk separate from the over-provisioning pool as the first unaligned chunk.

29. A method for managing a storage device, comprising: receiving, by the storage device, a command to allocate a part of the memory of the storage device to a first name space including unaligned chunks; comparing, by a controller of the storage device, an amount of potential capacity loss of the first name space associated with the first name space with a set threshold value, and when the amount of potential capacity loss of the first name space exceeds the set threshold value, using a first over-provisioning chunk from an over-provisioning pool in an internal memory of the controller as the unaligned chunk of the first name space.

30. reporting, by the controller, information about a visible chunk pool including a first chunk to a host; hiding, by the controller, information about a hidden chunk pool including the first over-provisioning chunk from the host; The method according to claim 29, further comprising transmitting, by the host, a command to allocate a part of the memory to the first name space to the storage device.

31. The method according to claim 29, further comprising using, by the controller, the first over-provisioning chunk based on a privacy designation of the first name space.

32. The method according to claim 29, further comprising using, by the controller, the first over-provisioning chunk based on a group number or format of the first name space.

Images