SEPARATE LARGE DATA BLOCKS FOR DATA STORAGE SYSTEMS

Abstract

Methods and facilities for efficiently handling large data files and their updates in NAND memory. An example provides a data storage system configured to reduce the frequency of data relocations by dividing a large data file into a multitude of subfiles. The size of such subfiles is chosen to reduce the likelihood of host relocation conflicts and the extent of write amplification, thereby enabling the data storage system to provide a better quality of service while essentially maintaining acceptable levels of other relevant performance characteristics.In some examples, a sequence of host commands for read-modify-write is handled by generating a copy of affected subfiles in a data buffer, applying subfile updates to the copy in the data buffer in accordance with the sequence, and moving the affected subfiles to the NAND memory using the updated versions of them from the data buffer.

Description

REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Non-Provisional Application No. 18 / 449,428, entitled "SEGREGATING LARGE DATA BLOCKS FOR DATA STORAGE SYSTEM," filed August 14, 2023, in the United States Patent and Trademark Office, which claims priority to U.S. Provisional Application No. 63 / 386,938, filed December 12, 2022, and is hereby incorporated by reference for all purposes. AREA

[0002] This application relates generally to data storage devices and in particular, but not exclusively, to handling updates of relatively large blocks of data. BACKGROUND

[0003] This section presents aspects that may contribute to a better understanding of the disclosure. Accordingly, the statements in this section should be read in this light and not as assumptions about what constitutes prior art and what does not.

[0004] Write amplification (WA) is an undesirable phenomenon associated with flash memory and solid-state drives (SSDs) that can result in the actual amount of information physically written to the storage medium being significantly larger than the logical amount of data intended to be written. For example, because the erase operation has a coarser granularity than the write operation, a process that performs erase and write operations on user data typically results in user data and metadata being moved (or rewritten) more than once. Consequently, in some examples, rewriting a data block results in a previously used portion of the flash memory being read, updated, and written to a new location, first erasing the new location if that location was previously used at some point.Due to the different granularity of erase and write operations, larger portions of the flash memory are typically erased and rewritten compared to the amount of new data. This different granularity increases the number of write operations, which can shorten the lifespan of the corresponding data storage device. In addition, the larger volume of write operations can consume bandwidth, which adversely affects the throughput of the data storage device. SUMMARY

[0005] Disclosed herein are various embodiments of methods and apparatus for efficiently handling large data files and their updates in NAND memory. In one example, a data storage system is provided configured to reduce the frequency of data relocations by dividing a large data file into a plurality of subfiles. The size of such subfiles is selected to reduce the likelihood of host relocation conflicts occurring and the extent of write amplification, thereby enabling the data storage system to provide better quality of service (QoS) while substantially maintaining acceptable levels of other relevant performance characteristics.In some examples, a sequence of host read-modify-write commands is handled by generating a copy of affected subfiles in a data buffer, applying subfile updates to the copy in the data buffer in accordance with the sequence, and relocating the affected subfiles in NAND memory using the updated versions thereof from the data buffer.

[0006] According to one embodiment, a data storage device is provided, comprising: a non-volatile memory for storing data; a second memory for storing a logical-to-physical (L2P) table and a sub-file mapping table; and a controller coupled to the non-volatile memory and the second memory and configured to: in response to a host command to write a large data file to the non-volatile memory, subdivide the large data file into a plurality of sub-files, wherein the large data file has a file size greater than a first fixed size, and wherein each sub-file of the plurality of sub-files has a respective size less than or equal to the first fixed size;Storing a first mapping of the plurality of sub-files in the sub-file mapping table, the first mapping including a respective physical wordline address for each sub-file of the plurality of sub-files; causing the plurality of sub-files to be written to the non-volatile memory based on the first mapping; and accessing the L2P table and the sub-file mapping table to control a store operation for the large data file in the non-volatile memory.

[0007] According to another embodiment, a method is provided performed by a data storage device, the method comprising: in response to a host command to write a large data file to non-volatile memory, dividing, via a controller, the large data file into a plurality of sub-files, wherein the large data file has a file size greater than a first fixed size, and wherein each sub-file of the plurality of sub-files has a respective size less than or equal to the first fixed size; storing, via the controller, a first mapping of the plurality of sub-files in a sub-file mapping table, wherein the first mapping includes, for each sub-file of the plurality of sub-files, a respective physical word line address;Causing, via the controller, the plurality of subfiles to be written to the non-volatile memory based on the first allocation; and accessing, via the controller, the L2P table and the subfile allocation table to control a save operation for the large data file to the non-volatile memory.

[0008] According to another embodiment, a data storage device is provided, comprising: means for dividing a large data file into a plurality of sub-files in response to a host command to write the large data file to non-volatile memory, wherein the large data file has a file size greater than a first fixed size, and wherein each sub-file of the plurality of sub-files has a respective size less than or equal to the first fixed size; means for storing a first mapping of the plurality of sub-files in a sub-file mapping table, wherein the first mapping includes, for each sub-file of the plurality of sub-files, a respective physical word line address; means for causing the plurality of sub-files to be written to the non-volatile memory based on the first mapping;and means for accessing an L2P table and the subfile allocation table to control a storage operation for the large data file in the non-volatile memory;

[0009] Various aspects of the present disclosure provide improvements in data storage devices, for example, optimizing the processes by which inputs / outputs from host devices are handled by data storage devices. The present disclosure may be embodied in various forms, including hardware or circuitry controlled by software and / or firmware, or combinations thereof. The foregoing summary is intended merely to provide a general idea of ​​various aspects of the present disclosure and in no way limits the scope of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram illustrating a data storage system in which various embodiments may be implemented. Fig. 2 is a block diagram illustrating a memory layout used in the data storage system of Fig. 1 can be used, according to one embodiment. Fig. 3 is a block diagram illustrating an exemplary subfile allocation table used in the data storage system of Fig. 1 can be used, according to one embodiment. Fig. 4 is a flowchart illustrating a host write operation performed in the data storage system of Fig. 1 is carried out, according to one embodiment. Fig. 5 is a flowchart illustrating read-modify-write operations performed in the data storage system of Fig. 1, according to one embodiment. Fig. 6-9 are block diagrams illustrating data layouts in the memory layout of Fig. 2 according to various examples. DETAILED DESCRIPTION

[0010] In the following description, numerous details are set forth, such as data storage device configurations, control operations, and the like, to provide an understanding of one or more aspects of the present disclosure. It will be readily apparent to those skilled in the art that these specific details are merely exemplary and are not intended to limit the scope of this application. In particular, the functions associated with the controller may be performed by hardware (e.g., analog or digital circuitry), a combination of hardware and software (e.g., program code or firmware stored in a non-transitory computer-readable medium executed by a processor or control circuitry), or any other suitable means.The following description is intended only to provide a general overview of various aspects of the present disclosure and does not limit the scope of the disclosure in any way. Furthermore, it will be apparent to those skilled in the art that, although the present disclosure relates to NAND memory, the concepts discussed herein may be applicable to other solid-state memory types such as NOR, PCM ("Phase Change Memory"), ReRAM, etc.

[0011] Fig. Figure 1 is a block diagram illustrating a data storage system 10 in which embodiments may be implemented. System 10 includes a data storage device 102 connected to a host device 190 via a communication path 180. In one embodiment, communication path 180 may be implemented using an electrical bus, a wireless connection, or other suitable data connection. Data storage device 102 may be a flash memory device, such as an SSD, flash memory, or other suitable non-volatile memory (NVM).

[0012] In some implementations, the data storage device 102 may be embedded in the host device 190. In some other embodiments, the data storage device 102 may be detachable from the host device 190, e.g., it may be detachably coupled to the host device 190 according to a detachable Universal Serial Bus (USB) configuration. In some embodiments, the data storage device 102 may be used as an embedded storage drive, e.g., a mobile embedded storage drive, an enterprise storage drive (ESD), a client storage device, a cloud storage drive, or other suitable data storage device.

[0013] As in Fig. 1, the data storage device 102 includes a host device interface 104, an electronic controller 110, an NVM 130, and a volatile memory (e.g., DRAM) 150. In operation, the host device interface 104 enables communication between the data storage device 102 and the host device(s) 190. Such communication may include, among other things, the transfer of data between the NVM 130 and the host device(s) 190. The NVM 130 includes memory chips 170, which may include any type or suitable combination of NAND flash devices, NOR flash devices, and other suitable non-volatile memory devices. The memory chips 170 may be organized into channels, with each of the channels based on a corresponding bus, e.g., a bus. B. an 8-bit bus that connects the corresponding subset of memory chips 170 to the controller 110.Individual memory chips 170 may further be organized into a hierarchy of levels, blocks, and pages. The NVM 130 and / or individual memory chips 170 may also include support circuitry (in . Fig. 1 not explicitly shown) such as read and write circuits. Such read / write circuits may be implemented in a single component or divided into separate components, such as a read circuit component and a separate write circuit component. In one embodiment, DRAM 150 is used, among other things, to store an L2P table 160. In operation, data storage device 102 uses L2P table 160 to translate logical addresses of input / output (I / O) requests into corresponding flash memory addresses. The layer that performs the translation is referred to as the flash translation layer (FTL).

[0014] The controller 110 includes components such as circuitry, firmware, and software that connect the NVM 130 to the host device interface 104, but for clarity, only some of these components are shown in Fig. 1. For example, the controller 110 may include: (i) an embedded processor 112; (ii) an electrically erasable firmware read-only memory (ROM, in Fig. 1 not explicitly shown); (iii) a DRAM controller 114; (iv) an error correction code (ECC) circuit or module 116; and (v) a flash component interface (in Fig. 1). In some embodiments, the controller 110 may also include the DRAM 150 or other functionally similar volatile memory in which the L2P table 160 is stored.

[0015] The processor 112 is configured to support, for example, some or all of the following operations: wear leveling, bad block management, data encryption, error correction coding, garbage collection, trim, address mapping, and other relevant operations. The DRAM controller 114 acts as the electronic controller of the DRAM 150. The ECC entity 116 may typically include two sub-modules, where a first of the sub-modules performs a first ECC applied to data stored in the NVM 130, and where a second of the sub-modules performs a different second ECC applied to data stored in the DRAM 150, including data from the L2P table 160 and other tables and / or control data structures that may be stored therein.

[0016] The host device 190 can address data stored in the NVM 130 using a logical address. However, the data in the NVM 130 is stored at physical addresses. The L2P table 160 is used to map the logical address used by the host device 190 to the physical address at which the data is actually stored in the NVM 130. When the host device 190 requests to read data, the controller 110 can retrieve the physical address from the L2P table 160 to access the requested data. When the host device 190 requests to write or update data in the NVM 130, the controller 110 can update the L2P table 160 accordingly.

[0017] A master L2P table may be stored in the NVM 130, but to be efficiently used or updated by the controller 110, at least a relevant portion of the master L2P table is stored in the DRAM 150, e.g., in the L2P table 160. When the L2P table 160 is updated, the updates must be written back to the master L2P table stored in the NVM 130. During the design process of the data storage device 102, it may be determined whether the DRAM 150 is specified to contain a copy of the entire master L2P table for the entire logical address space. A decision not to contain the entire master L2P table in the DRAM 150 may, for example, be due to a size limitation of the DRAM 150.Similar design decisions may also be made with respect to other tables that may be used instead of, in addition to, or in conjunction with L2P table 160 according to various embodiments.

[0018] In some examples of page-level L2P mapping, a physical address can include a channel number, a chip number, a block number, and a page number. With a page size of 4 KB, a 32 TB NVM 130 might require approximately 32 GB of such L2P entries. With the additional ECC overhead, this volume of L2P entries can be accommodated by, for example, a 40 GB DRAM 150. This DRAM capacity estimate is approximately linear in magnitude with the data capacity of NVM 130.

[0019] Although the control 110 in Fig. 1 as being connected to and using DRAM 150, alternative embodiments are also possible. For example, in such an embodiment, the controller 110 may use an integrated cache memory, such as static random access memory (static RAM or SRAM), that is part of the controller circuitry for similar functions. In another embodiment, the controller 110 may use a dedicated portion of NVM 130 as storage for the L2P table 160 and any associated mapping tables instead of DRAM 150.

[0020] In a data center deploying the data storage system 10, data files ranging in size from 1 GB to 10 TB are common. In operation, multiple users can typically access and rewrite several terabytes of data at a given rate. With a read / write granularity of 4 KB, frequent changes by different users to the same large files can result in frequent read-change-write (RMW) operations, sometimes characterized by significant and undesirable WA effects and the corresponding degradation of QoS metrics. In some examples, such frequent changes to the same files are due to host data model training and / or data iteration at the same memory address.Another undesirable impact of WA concerns the operation of the data processing unit (DPU), where slowing down data access may lead to further performance and / or QoS limitations of the corresponding data storage system 10.

[0021] At least some of the above and possibly some other related prior art problems may be advantageously addressed using the various examples, aspects, features, and / or embodiments disclosed herein. In some examples, data storage system 10 is configured to reduce the frequency of data relocations by dividing large data files into corresponding pluralities of subfiles and then using the subfiles for updates associated with the host's RMW operations. The size of such subfiles is appropriately selected to advantageously reduce the likelihood of host relocation conflicts occurring and the extent of WA, thereby enabling data storage system 10 to provide better QoS while substantially maintaining acceptable levels of other relevant performance characteristics.

[0022] Here, RMW is a class of atomic operations that both read a memory location and write a new value to the memory location, either with a completely new value or a function of the previous value. RMW operations can be used, for example, to read a specific page or to change words, bytes, or bits on a page. A read command of an RMW operation causes the desired data to be copied from flash memory to a data buffer. The modify command of the RMW operation then causes the data in the data buffer to be modified as needed. A write command of the RMW operation causes the modified data to be written back to flash memory. In some examples, RMW operates with a minimum write unit, which can be smaller than one page. In some additional examples, multiple pages are programmed simultaneously.

[0023] Some embodiments disclosed herein implement a trade-off between write amplification and performance. For example, smaller allocation unit sizes may result in reduced write amplification because less data is read, modified, and then written back to the NAND. Conversely, in some embodiments, increasing the allocation unit size may slightly increase write amplification, e.g., by rewriting more information each time the host modifies / writes a particular data area, at the expense of endurance but with the benefit of better performance at certain times. Also, note that write amplification is the total number of writes to the NAND divided by the host writes to the device.Therefore, write amplification can be influenced by additional factors beyond the granularity differences mentioned above, with additional example factors including media management policies related to read disturbances, data retention, error mitigation, redundancy, metadata, etc.

[0024] At least some of the approaches disclosed herein are applicable to hard disk drives (HDDs).

[0025] Fig. Figure 2 is a block diagram illustrating an example memory layout 200 that may be used in data storage device 102, according to one embodiment. Other layouts may also be used in other embodiments. At least some example values ​​described below with reference to Fig. 2 may be different in other examples or embodiments of the memory layout 200.

[0026] According to memory layout 200, a first meta-block labeled 2021 has memory blocks in a first physical chip labeled Chip 0. A second meta-block labeled 2022 has memory blocks in a second physical chip labeled Chip 1. Together, meta-blocks 2021 and 2022 form a jumbo block 204. Each of the physical chips Chip 0 and Chip 1 is divided into four corresponding logical chips, each labeled Logical Chip 0 through Logical Chip 3. Logical chips 0, 1, 2, 3 can be accessed via channels 0, 1, 2, 3, respectively. Each of the logical chips has four corresponding levels, each labeled Level 0 through Level 3. Each of the levels is connected to word lines WL0, WL1, ..., WL19. Each word line (WL) typically includes a plurality (for example, four) of corresponding string lines (in Fig. 2 not explicitly shown). Each of the levels includes twenty respective WL blocks, one of which is in Fig. 2 is designated 210. The memory layout 200 has a total of 640 WL blocks 210. Each of the meta blocks 2021 and 2022 has 320 respective WL blocks 210.

[0027] In an illustrative example, the WL block 210 comprises triple-level cells (TLCs), each capable of storing three bits. In this example, the WL block 210 has a size of 48 KB and can store twelve 4-KB pages. Each row of WL blocks connected to the same word line WLn (n = 0, 1, ..., 19) in the meta-block 202 i(i=1, 2) has a size of 768 KB. Each row of WL blocks connected to the same word line WLn in jumbo block 204 has a size of 1,536 KB. The read / write granularity in memory layout 200 is one page. The erase granularity in memory layout 200 is one level. In some other examples, more than two meta blocks 202 may be logically combined to form a corresponding jumbo block. In various examples, a WL block may include different types of NAND memory cells, such as single-level cells (SLCs), multiple-level cells (MLCs), or quad-level cells (QLCs). In such various examples, a corresponding WL block has a corresponding size that may differ from 48 KB.

[0028] In one embodiment, data storage device 102 is operable to divide a large data file into a plurality of subfiles at the WL level. The host may specify the size of the input file to be written to NVM 130 using the Non-Volatile Memory Express (NVMe) protocol or an equivalent logical storage interface protocol. The data storage device may specify a "large" file using optimal read / write / share size parameters as described in storage interface protocols. Note that the host may use multiple write commands or write operations to transfer a "large" file, each of which is smaller than the "large" file size. A "large" file herein is a file that is larger than the combined size of the WL blocks (such as 210, Fig. 2), which is connected to the same word line WLn in meta-block 202 ior connected in jumbo block 204. In the illustrative example above, a file that is "large" in this sense is larger than the meta-block wordline (MBW) capacity of 768 KB or the jumbo-block wordline (JBW) capacity of 1,536 KB.

[0029] In some examples, the MBW capacity is not limited to a single physical chip and may be distributed similarly across multiple physical chips, such as two physical chips or four physical chips. Thus, a corresponding JBW capacity may, for example, comprise four MBW capacities in four times as many physical chips. In some examples, a single physical chip may have multiple levels, such as two, four, or more levels, e.g., as in Fig. 2. If a physical chip has only one or two levels, the MBW capacity may span more physical chips. Conversely, if a physical chip has four or more levels, the MBW capacity may span fewer physical chips, with the JBW capacity spanning more units of MBW capacity. In various examples, the MBW sizing may also depend on the specific NAND chip architecture used in the corresponding NVM.

[0030] For a given large data file from the host 190, an allocation table for each of these MBW / JBW is defined at the FTL level by specifying the subfiles of that data file in MBW / JBW size. In other words, a large data file is logically partitioned into MBW subfiles (or JBW subfiles), with the corresponding L2P allocations stored in the controller's memory. For each subfile smaller than the MBW or JBW capacity, a plurality of such smaller subfiles from different original data files can be combined to form a "virtual" subfile that fills the MBW or JBW capacity. In some examples, to maintain an acceptable level of performance, such virtual subfiles are written to a memory partition containing SLCs. When concurrent operations (e.g.,Since multiple operations (including RMW operations) are required for two or more host files associated with a virtual subfile, the SLC partition is typically better suited to efficiently handle concurrent operations. Data storage device 102 further serves to generate L2P mappings for various MBW subfiles (or JBW subfiles) of large data files and to store the generated mappings in L2P table 160 and / or in a supplemental subfile mapping table (e.g., 300, . Fig. 3) which is linked to the L2P table 160.

[0031] Fig. 3 is a block diagram illustrating an exemplary subfile allocation table 300 according to one embodiment. For illustrative purposes and without implicit limitations, Fig. 3, only a portion of Table 300, corresponding to two host files, is explicitly shown. The host file identifiers (IDs) of these two files are listed in column 302 of Table 300. The first host file has host file ID=0 and a size of 1,936 KB. The second host file has host file ID=1 and a size of 1,136 KB. The first host file (host file ID=0) is divided into three subfiles with subfile IDs 0, 1, and 2, listed in column 304 of Table 300. The size of these three subfiles is 768, 768, and 400 KB, respectively, and is listed in column 306 of Table 300. The second host file (host file ID=1) is divided into two subfiles with subfile IDs 0 and 1, listed in column 304 of Table 300. The size of these two subfiles is 368 and 768 KB, respectively, and is listed in column 306 of Table 300.

[0032] At the Fig. The example table 300 shown in Figure 3 is an MBW mapping table, with the corresponding attributes of the MBW mapping being specified in columns 308-316 of the table. Based on the description provided, those skilled in the art will be able to create and use a similar JBW mapping table without undue experimentation. In the example shown, columns 308, 310, 312, 314, and 316 list MBW IDs, MBW offsets, MBW physical addresses, MBW cell types, and MBW logical chip IDs, respectively. Note that the subfiles with the (host file ID, subfile ID) values ​​(0, 2) and (1, 0) form a virtual MBW subfile. The size of the virtual subfile is 768 KB (= 400 KB + 368 KB). The two parts of this virtual MBW subfile are located at different MBW offsets of 0 and 100, respectively, as indicated in column 310 MBW Offsets.The corresponding physical MBW address of the two parts is the same, i.e., 100h, as indicated in column 312, Physical MBW Address. Also note that the virtual MBW subfile is located in an SLC partition for the reasons stated above, while the other listed MBW subfiles are located in TLC partitions. The logic chips containing the SLCs have MBW logic chip IDs = 8, 9, 10, and 11, as indicated in column 316 of Table 300. The logic chips containing the TLCs have MBW logic chip IDs = 0, 1, 2, 3, 4, 5, 6, 7, 12, 13, 14, and 15, as further indicated in column 316 of Table 300.

[0033] During an RMW operation, the data corresponding to an MBW may be modified in a portion thereof, which may be any size between the read / write granularity (which is 4 KB in the example above) and the full MBW capacity (which is 768 KB in the example above). In one example, the data storage device 102 is configured to perform data modifications using a data buffer physically located, for example, in the DRAM 150 or in an internal RAM of the controller 110. Thus, the corresponding portion of the data buffer is at least 768 KB in size. In another example, the data storage device 102 is configured to perform data modifications using a host memory buffer (HMB) located in the host 190.Once the corresponding portion of RAM is full or another request to use the same RAM resource is received, the MBW relocation may occur as part of an RMW operation. The latter relocation may be implemented, for example, using a regular relocation thread of the data storage device 102. It should also be noted that if multiple MBWs undergo RMW operations substantially concurrently, the corresponding relocations may occur such that a new MBW (i.e., the relocation target MBW) may be configured to contain multiple 4 KB units from multiple original MBWSs (i.e., the relocation source). In such cases, the corresponding subfile allocation table, such as table 300, is updated accordingly, e.g., similar to the table updates performed for write operations initiated by the host 190.

[0034] Fig. 4 is a flowchart illustrating a method 400 for performing a host write operation in data storage device 102 according to one embodiment. Method 400 includes controller 110 receiving a write command from host 190 (at block 402). The received write command specifies, among other things, the size of the data file to be written to NVM 130.

[0035] The method 400 also includes the controller 110 determining whether the data file to be written to the NVM 130 is a "large" data file (at decision block 404). In one embodiment, such a determination is made at decision block 404 by comparing the file size to the MBW capacity, which in the above example is 768 KB. In another embodiment, such a determination is made at decision block 404 by comparing the file size to the JBW capacity, which in the above example is 1536 KB.

[0036] If the file size is larger than the MBW (or JBW) capacity ("Yes" in decision block 404), method 400 includes controller 110 dividing the data file into a plurality of subfiles (in block 406). The plurality of subfiles includes one or more subfiles with a size equal to the MBW (or JBW) capacity. For some data files, the plurality of subfiles also includes at least one subfile with a size smaller than the MBW (or JBW) capacity. As mentioned above, the smaller subfiles from different host data files can be used to form a virtual subfile that fills the corresponding MBW or JBW to capacity.

[0037] The method 400 also includes the controller 110 generating an MBW (or JBW) mapping of the subfiles defined in block 406, and further includes the controller 110 generating an MBW (or JBW) mapping table detailing the generated MBW (or JBW) mapping (in block 408). In some examples, the generated MBW mapping table is similar to table 300 ( Fig. 3). The method 400 also includes the controller 110 storing the generated MBW mapping table (or JBW mapping table) in the DRAM 150 (in block 408).

[0038] If the file size is less than or equal to the MBW capacity (or JBW capacity) ("No" in decision block 404), the method 400 includes the controller 110 mapping the entire host data file to a physical address in the NVM 130 (in block 410). The method 400 also includes the controller 110 updating the L2P table 160 in the DRAM 150 to store the generated mapping therein (in block 410).

[0039] Method 400 also includes controller 110 configuring the appropriate write circuitry of data storage device 102 to write the host data file to NVM 130 based on the applicable mapping (at block 412). If the operations preceding block 412 are the operations of block 408, the applicable mapping is the appropriate MBW mapping (or JBW mapping). If the operations preceding block 412 are the operations of block 410, the applicable mapping is the appropriate conventional L2P mapping.

[0040] Fig. 5 is a flowchart illustrating a method 500 for performing RMW operations in data storage device 102 according to one embodiment. In some examples, method 500 may be performed, for example, after method 400 ( Fig. 4), wherein a large host data file is divided into subfiles, with the corresponding MBW (or JBW) mapping specified in table 300 or a functionally similar table. For illustrative purposes and without implicit limitations, method 500 is described below with reference to MBW subfiles.

[0041] The method 500 includes the controller 110 receiving a sequence of RMW commands from the host 190 for a data file stored in the NVM 130 and copying one or more affected MBW subfiles from the NVM 130 to a data buffer (at block 502). For the specific example described above, the data buffer space allocated to each of the copied MBW subfiles is at least 768 KB. The method 500 also includes applying updates that track the RMW operations of the RMW command sequence to the copy of the MBW subfiles in the data buffer (at block 504). The RMW operations of the sequence are not applied to the source MBW subfiles stored in the NVM 130 at block 504.

[0042] Method 500 also includes determining (in decision block 506) whether the data buffer space allocated to the copy of the MBW subfiles should be reallocated for another purpose. In a representative example, such reallocations are subject to applicable buffer management policies. If it is determined that the reallocation is not yet pending ("No" in decision block 506), processing of method 500 returns to the operations of block 504. Otherwise ("Yes" in decision block 506), processing of method 500 continues to perform the operations of block 508.

[0043] Method 500 includes operations directed to relocating the affected MBW subfiles to new locations of respective MBW sizes in NVM 130 (at block 508). In one example, controller 110 configures the corresponding write circuitry of data storage device 102 to write a current copy (i.e., a copy updated via operations of block 504) of an MBW subfile stored in the data buffer to a new MBW-sized location in NVM 130. Controller 110 may also invalidate the data of that MBW subfile stored at the previous location in NVM 130. In some examples, controller 110 may also generate a new virtual MBW subfile, the smaller subfiles of which it is comprised coming from a set of host data files that is different from the set of host data files in the corresponding previous virtual MBW subfile.

[0044] The method 500 also includes the controller 110 updating the MBW mapping table (in block 510). More specifically, the controller 110 performs updates to the MBW mapping table (in block 510) to record therein the changes in the MBW subfile mapping that correspond to the operations performed in block 508 of the method 500. For example, in the Fig. 3, the table entries for the MBW subfiles with the (host file ID, subfile ID) values ​​(0, 0) and (0, 1) are updated in block 510 to change the respective old physical MBW addresses listed in column 312 of table 300 to the respective new physical MBW addresses when these MBW subfiles are relocated in the NVM 130 due to operations performed in block 508 of method 500. Other entries in table 300 may also be updated accordingly to reflect the corresponding operations performed in block 508 of method 500.

[0045] Fig. 6-9 are block diagrams illustrating data layouts in jumbo block 204 according to various examples. Different data layouts may be created, e.g., with different respective scheduling algorithms used to implement the operations in blocks 408 and 410 of method 400. In the Fig. 6-9, "JPC N1-N2" denotes parts of JBW subfiles the size of a WL block, where the number N1 is the identifier of the JBW subfile and the number N2 is the identifier of the subfile part. An example of a WL block is the one shown in Fig. 2. JBW subfiles are allocated to respective portions of jumbo block 204 using the operations of block 408 of method 400. "Normal" refers to a WL block containing "small" file data allocated thereto using the operations of block 410 of method 400.

[0046] Fig. Figure 6 illustrates an example of a data layout created with enforced ordering. In a representative example, enforced ordering is used to ensure that the data is distributed evenly and in an orderly manner across jumbo block 204 so that host or garbage collection writes are not interleaved with JBW subfile writes. In the example of Fig. 6, the forced sorting results in: (i) three JBW subfiles being written to word lines WL0, WL1, and WL2, respectively; and (ii) conventional writes being written to word lines WL3, WL4, and WL5. In one example, the forced sorting is achieved by giving higher priority to JBW subfile writes and choosing a priority threshold that prevents conventional writes from interleaving with JBW subfile writes. Additionally, one chip can be prevented from being ahead of another in terms of programmed volume by setting the limit on how far ahead one chip can be to exactly zero.

[0047] Fig. Figure 7 shows another example of a data layout that results from allowing conventional host or garbage collection writes to be interleaved with JBW subfile writes. In the example of Fig. 7, the interleaving of such writes results in: (i) three JBW subfiles being written to word lines WL0, WL2, and WL5, respectively, and (ii) conventional writes being written to word lines WL1, WL3, WL4, and WL6. In some examples, correlated parallelism and sorting between different chips can still be implemented in a similar manner to the example of Fig. 6, so that nesting has little or no adverse performance impact. Pauses are provided between JBW subfile writes to allow for queued conventional writes and / or other activities.

[0048] Fig. Figure 8 illustrates yet another example of a data layout resulting from scheduling writes in FIFO (first in / first out) order of WL blocks. In the example of Fig. 8, FIFO scheduling results in each of the three JBW subfiles having corresponding portions on two different word lines. Specifically, the WL blocks JPC0-N2 (where N2 = 0, 1, ..., 31) of the first (N1 = 0) JBW subfile are distributed across word lines WL0 and WL1. The WL blocks JPC1-N2 (where N2 = 0, 1, ..., 31) of the second (N1 = 1) JBW subfile are distributed across word lines WL1 and WL2. The WL blocks JPC2-N2 (where N2 = 0, 1, ..., 31) of the third (N1 = 2) JBW subfile are distributed across word lines WL2 and WL3. Even with such a distribution, the degree of parallelism can usually be relatively high. This type of FIFO scheduling allows for relatively favorable data layouts during periods of relatively low activity. If no chip is allowed to program further than other chips and / or JPC writes are prioritized, the probability of the Fig. 8 illustrated data layout patterns.

[0049] Fig. Figure 9 illustrates another example of a data layout resulting from FIFO scheduling, where some chips are allowed to program further than others and the system is relatively heavily loaded by mixed workloads. In the example of Fig. 9, such scheduling results in: (i) logic chips 1, 3, 5, and 7 being downprogrammed to WL3; (ii) logic chips 0 and 6 being downprogrammed to WL4; and (iii) logic chips 2 and 4 being downprogrammed to WL5.

[0050] In some examples, to avoid power outages and / or improve performance, an update of a small portion of a JBW subfile is initially scheduled, which later triggers a corresponding rewrite of a larger data segment to improve the degree of parallelism. In such examples, the following sample sequence of events might occur: (a) the host 190 issues a write command for a 4 KB page; (b) the controller 110 looks up the 4 KB page in the L2P table 160 and / or the subfile allocation table 300 and determines that the 4 KB page is located in a JBL subfile; (c) the controller 110 configures the write circuitry to update the 4 KB page in the NVM 130; (d) the controller 110 notifies the host 190 of the completion of the write command; (e) the controller 110 schedules the corresponding update of the JBL subfile with the updated 4 KB page; and (f) the controller 110 configures the write circuit to perform the update of the JBL subfile in the background, e.g., when the workload allows, and the write circuit relocates the JBL subfile to achieve a more favorable data layout in terms of parallelism, e.g., similar to that in Fig. 6 illustrated data layout.

[0051] In some examples, an update may occur in two stages, with the first stage writing the portion of data modified by the host to non-volatile storage (a safe option against power loss and relatively easy to implement to improve performance), and the second stage writing the entire data block to a more permanent location. The two-stage update is also expected to work well with coalescing, for example, by grouping multiple changes together and updating them in a single action, which can have a positive impact on performance and write amplification.

[0052] With respect to the processes, systems, methods, heuristics, etc. described herein, it is understood that although the steps of such processes, etc., have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in a different order than that described herein. It is further understood that certain steps could be performed concurrently, that other steps could be added, or that certain steps described herein could be omitted. In other words, the descriptions of the processes herein are provided for the purpose of illustrating particular implementations and should not be construed in any way to limit the claims.

[0053] Accordingly, it is to be understood that the foregoing description is intended to be illustrative and not restrictive. Many other embodiments and applications than the examples provided would be apparent upon reading the foregoing description. The scope of protection should be determined not by reference to the foregoing description, but should instead be determined by reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and intended that future developments will occur in the technologies discussed herein and that the disclosed systems and methods will be incorporated into such future embodiments. In summary, it is understood that the application is subject to modification and variation.

[0054] All terms used in the claims should be given their broadest reasonable interpretations and their ordinary meanings as understood by those skilled in the technologies described herein, unless an explicit statement to the contrary is made herein. In particular, the use of singular articles such as "a," "an," "the," "this," etc., should be read to specify one or more of the specified elements, unless a claim provides an explicit limitation to the contrary.

[0055] Unless expressly stated otherwise, any numerical value and range should be interpreted as approximate, as if the value or range were preceded by the word "about" or "approximately."

[0056] Reference herein to "a single embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the implementation. The phrase "in an embodiment" in various places throughout the specification does not necessarily refer to the same embodiment, nor do separate or alternative embodiments necessarily exclude other embodiments. The same applies to the term "implementation."

[0057] Unless otherwise specified herein, the use of the ordinal adjectives "first", "second", "third", etc., to designate one object among a plurality of like objects merely indicates that reference is made to different instances of such like objects, and is not intended to imply that the like objects so designated must be in any corresponding order or sequence, whether in time, space, ranking, or any other manner.

[0058] Unless otherwise specified herein, the conjunction "when," in addition to its plain meaning, may also or alternatively be interpreted to mean "as soon as" or "upon" or "in response to determining" or "in response to detecting," which interpretation may depend on the relevant specific context. For example, the phrase "when it is determined" or "when [a specified condition] is detected" may be interpreted to mean "upon determination" or "in response to determining" or "upon detecting [the specified condition or event]" or "in response to detecting [the specified condition or event]."

[0059] The functions of the various elements shown in the figures, including the functional blocks referred to as "processors" and / or "controllers," may be provided both through the use of dedicated hardware and through hardware capable of executing software in conjunction with suitable software. When provided by a processor, the functions may be provided by a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which may be shared.Furthermore, the explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly and without limitation include digital signal processor (DSP) hardware, network processors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), read-only memory (ROM) for storing software, random-access memory (RAM), and non-volatile memory. Other hardware, conventional and / or custom, may also be included. Likewise, any switches shown in the figures are conceptual only. Their function may be performed by the operation of program logic, by dedicated logic, by interaction between program controller and dedicated logic, or even manually, with the particular technique being chosen by the implementer as more clearly indicated by the context.

[0060] As used in this application, the term "circuitry" may refer to one or more or all of the following: a) pure hardware circuit implementations (such as implementations in solely analog and / or digital circuitry); b) combinations of hardware circuitry and software such as (as applicable): (i) a combination of analog and / or digital hardware circuitry with software / firmware, and (ii) any parts of hardware processor(s) with software (including digital signal processor(s)), software, and memory that together cause a device such as a mobile phone or a server to perform various functions); and (c) hardware circuitry and / or processor(s), such as microprocessor(s) or parts of microprocessor(s), that require software (e.g., firmware) to operate, but the software may not be present if it is not required for the operation." This definition of circuitry applies to all uses of that term in this application, including all claims. As a further example, the term "circuitry" as used in this application also includes the implementation of only one hardware circuit or processor (or multiple hardware processors), or a portion of a hardware circuit or processor, and the associated software and / or firmware. The term "circuitry" also includes, for example, and where applicable to the respective claim element, a baseband integrated circuit or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular device, or other computing or networking device.

[0061] The term "SUMMARY" in this specification is intended to introduce some embodiments, with additional embodiments being described in the "DETAILED DESCRIPTION" and / or with reference to one or more drawings. "SUMMARY" is not intended to identify essential elements or features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0062] "SUMMARY" is provided to help the reader quickly appreciate the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Additionally, it will be appreciated from the foregoing "DETAILED DESCRIPTION" that various features in various embodiments are grouped together for convenience of disclosure. This method of disclosure should not be interpreted to reflect an intent that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in fewer than all of the features of any single disclosed embodiment.Thus, the following claims are hereby incorporated into the "DETAILED DESCRIPTION", with each claim standing on its own as separately claimed subject matter. QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited patent literature

[0000] US 18 / 449,428

[0001] US 63 / 386,938

[0001]

Claims

[1] Data storage device comprising: a non-volatile one for storing data; a second memory for storing a logical-to-physical (L2P) table and a subfile allocation table; and a controller coupled to the non-volatile memory and the second memory and configured to: dividing, in response to a host command to write a large data file to the non-volatile memory, the large data file into a plurality of sub-files, the large data file having a file size greater than a first fixed size, and each sub-file of the plurality of sub-files having a respective size less than or equal to the first fixed size; Storing a first mapping of the plurality of sub-files in the sub-file mapping table, the first mapping including a respective physical word line address for each sub-file of the plurality of sub-files; Causing the plurality of subfiles to be written to the non-volatile memory based on the first allocation; and Access the L2P table and the subfile allocation table to control a save operation for the large data file to non-volatile memory. [2] The data storage device of claim 1, wherein the first fixed size is a meta-block wordline capacity or a jumbo-block wordline capacity, wherein the jumbo-block wordline capacity is an integer multiple of the meta-block wordline capacity, and wherein the meta-block wordline capacity is a combined data capacity of NAND memory blocks connected to the same wordline in a single physical chip of the non-volatile memory or an integer multiple of the combined data capacity in one or more physical chips of the non-volatile memory. [3] The data storage device of claim 1, wherein the controller is further configured to: Storing, in response to a host command to write a small data file to the non-volatile memory, a mapping of the small data file in the L2P table, the small data file having a file size smaller than the first fixed size; and Cause the small data file to be written to non-volatile memory based on the small data file allocation. [4] The data storage device of claim 3, wherein the first allocation causes the plurality of sub-files to be interleaved with a plurality of small data files in the non-volatile memory. [5] The data storage device of claim 1, wherein the controller, in response to a sequence of host read-modify-write (RMW) commands, is further configured to: generating a copy of one or more affected sub-files of the plurality of sub-files in a data buffer; Applying subfile updates to the copy according to the sequence of RMW host commands; and In response to reallocating the data buffer, causing the one or more affected subfiles to be relocated in the non-volatile memory. [6] The data storage device according to claim 5, wherein the controller is further configured to update the first mapping in the sub-file mapping table according to the relocation. [7] The data storage device of claim 5, wherein the controller is configured not to apply the subfile updates corresponding to the sequence of RMW host commands to the one or more affected subfiles in the non-volatile memory until the relocation. [8] The data storage device of claim 1, wherein the first allocation causes a single sub-file of the plurality of sub-files in the non-volatile memory to occupy an array of NAND memory blocks associated with a single word line in a single physical chip of the non-volatile memory, or two or more instances of the array in one or more physical chips of the non-volatile memory. [9] Data storage device according to claim 8, wherein at least one NAND memory block in the array of NAND memory blocks stores both a smaller subfile of a first large data file and a smaller subfile of a second large data file; and where the smaller subfile of the first large data file and the smaller subfile of a second large data file have a combined size equal to the first fixed size. [10] The data storage device of claim 1, wherein the first allocation causes a single sub-file of the plurality of sub-files in the non-volatile memory to occupy a first array of NAND memory blocks connected to a first word line in a physical chip of the non-volatile memory and a second array of NAND memory blocks connected to a second word line in the physical chip of the non-volatile memory. [11] The data storage device of claim 1, wherein the first association causes the plurality of sub-files to be interleaved with a plurality of other data files or other sub-files in the non-volatile memory. [12] A method performed by a data storage device, the method comprising: in response to a host command to write a large data file to non-volatile memory, subdividing, via a controller, the large data file into a plurality of sub-files, wherein the large data file has a file size greater than a first fixed size, and wherein each sub-file of the plurality of sub-files has a respective size less than or equal to the first fixed size; Storing, via the controller, a first mapping of the plurality of sub-files in a sub-file mapping table, the first mapping including, for each sub-file of the plurality of sub-files, a respective physical word line address; Causing, via the controller, the plurality of sub-files to be written to the non-volatile memory based on the first allocation; and Accessing, through the controller, a logical-to-physical (L2P) table and the subfile mapping table to control a save operation for the large data file to non-volatile memory. [13] The method of claim 12, wherein the first fixed size is a meta-block wordline capacitance or a jumbo-block wordline capacitance, wherein the jumbo-block wordline capacitance is an integer multiple of the meta-block wordline capacitance, and wherein the meta-block wordline capacitance is a combined data capacitance of NAND memory blocks connected to the same wordline in a single physical chip of the non-volatile memory. [14] The method of claim 12, further comprising: in response to a host command to write a small data file to the non-volatile memory, storing, via the controller, a mapping of the small data file in the L2P table, the small data file having a file size that is smaller than the first fixed size; and Cause, via the controller, the small data file to be written to non-volatile memory based on the small data file allocation. [15] The method of claim 12, further comprising: Receiving, via the controller, a sequence of host read-modify-write (RMW) commands; generating, via the controller, a copy of one or more affected sub-files from the plurality of sub-files in a data buffer, wherein the one or more affected sub-files are affected by the sequence of RMW host commands; Applying, via the controller, subfile updates according to the sequence of RMW host commands to the copy; and in response to reallocation of the data buffer, causing, via the controller, relocation of the one or more affected sub-files in the non-volatile memory. [16] The method of claim 15, wherein the controller is configured to update the first mapping in the sub-file mapping table according to the relocation. [17] The method of claim 15, wherein the controller is configured not to apply the subfile updates corresponding to the sequence of RMW host commands to the one or more affected subfiles in the non-volatile memory until relocated. [18] The method of claim 12, wherein the first allocation causes a single sub-file of the plurality of sub-files in the non-volatile memory to occupy a first array of NAND memory blocks connected to a first word line in a physical chip of the non-volatile memory and a second array of NAND memory blocks connected to a second word line in the physical chip of the non-volatile memory. [19] Data storage device comprising: Means for dividing a large data file into a plurality of sub-files in response to a host command to write the large data file to non-volatile memory, wherein the large data file has a file size greater than a first fixed size, and wherein each sub-file of the plurality of sub-files has a respective size less than or equal to the first fixed size; means for storing a first mapping of the plurality of sub-files in a sub-file mapping table, the first mapping including a respective physical word line address for each sub-file of the plurality of sub-files; means for causing the plurality of sub-files to be written to the non-volatile memory based on the first assignment; and Means for accessing a logical-to-physical (L2P) table and the subfile mapping table to control a store operation for the large data file in non-volatile memory. [20] The data storage device of claim 19, further comprising: Means for receiving a sequence of host read-modify-write (RMW) commands; means for generating a copy of one or more affected sub-files of the plurality of sub-files in a data buffer, the one or more affected sub-files being affected by the sequence of RMW host commands; Means for applying subfile updates to the copy according to the sequence of RMW host commands; and Means for causing the one or more affected sub-files to be relocated in non-volatile memory in response to reallocation of the data buffer.

Images