Management of host file system defragmentation in data storage device

Abstract

A data storage device having a flash translation layer configured to handle file system defragmentation in a manner that avoids, reduces, and / or optimizes physical data movement in the flash memory. In an example embodiment, the memory controller maintains a backup table in its volatile memory that replaces related portions of a logical-to-physical table. An entry of the backup table is configured to track a source address and a destination address of a host defragmentation request and logically link to a corresponding entry of the logical-to-physical table, the logical component may support end-to-end data protection of user data, including using logical address tags, without physical data rearrangement in the flash memory. In some embodiments, physical data rearrangement corresponding to the file system defragmentation is performed in the flash memory in response to certain trigger events, which may improve input / output performance of the data storage device.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Non-Provisional Application No. 17 / 865,641, filed on July 15, 2022, and entitled “MANAGEMENT OF HOST FILE SYSTEM Defragmentation IN A DATA STORAGE DEVICE” and is hereby incorporated by reference in its entirety for all purposes. Technical Field

[0003] The present application relates generally to data storage devices, and more particularly, but not exclusively, to file system defragmentation. Background Art

[0004] This section introduces aspects that may help promote a better understanding of the present disclosure. Therefore, the description of this section should be interpreted from this perspective and should not be understood as an admission of the content in the prior art or the content that is not in the prior art.

[0005] In computing and data storage, fragmentation is the tendency of a file system to arrange file contents non-contiguously and / or out of sequence. File system fragmentation can negatively impact data access times and hinder data throughput. For example, in a hard drive, sequential data reads are fast, but seeking to different addresses is relatively slow. Since reading or writing a fragmented file typically requires many seeks, it is slower than reading or writing a contiguous file. Fragmentation can be fixed by reorganizing files and free space into contiguous areas, a process often referred to as "defragmentation." Since solid-state drives (SSDs) do not seek, defragmenting an SSD is generally not recommended. However, fragmentation still occurs in an SSD, which can adversely affect the overall performance of the SSD. Summary of the invention

[0006] Various embodiments of a data storage device with a flash translation layer are disclosed herein, and the flash translation layer is configured to handle file system defragmentation in a manner to avoid, reduce and / or optimize physical data rearrangement in a flash memory. In an example embodiment, a memory controller maintains a backup table, for example in its volatile memory, which replaces the relevant portion of a logical to physical (L2P) table. The entries of the backup table are configured to track the source address and destination address of a host defragmentation request and are logically linked to the corresponding entries of the logical to physical table, so that a logical component can support end-to-end data protection for user data including the use of logical address tags without physically rearranging user data in a flash memory. In some embodiments, physical data rearrangement corresponding to the file system defragmentation can be performed in the flash memory only in response to a selected triggering event, which can improve the input / output performance of the data storage device.

[0007] According to an example embodiment, a data storage device is provided, the data storage device comprising: a non-volatile memory for storing data; a second memory for storing an L2P table and a backup table; and a controller coupled to the non-volatile memory and the second memory and configured to: in response to a first host command having a source logical address and a destination logical address, update the backup table by a table entry having the source logical address and the destination logical address; logically link the table entry of the backup table with a corresponding entry of the L2P table; and access the table entry of the backup table and the corresponding entry of the L2P table to control memory operations on the data in the non-volatile memory. In various examples, the second memory may be a volatile memory associated with the controller or a dedicated partition (e.g., a control block or a portion) of the non-volatile memory.

[0008] According to another example embodiment, a method performed by a data storage device receiving a command from a host device is provided, the method comprising: updating, by a controller, a lookaside table with a table entry having a source logical address and a destination logical address specified in a first host command, the lookaside table stored in a control data memory; logically linking, by the controller, the table entry of the lookaside table with a corresponding entry of an L2P table stored in the volatile memory; and accessing, by the controller, the table entry of the lookaside table and the corresponding entry of the L2P table to control memory operations on user data stored in a non-volatile memory. In various examples, the control data memory may be a volatile memory associated with the controller or a dedicated partition (e.g., a control block or a portion) of the non-volatile memory.

[0009] According to another example embodiment, an apparatus for receiving a command from a host device is provided, the apparatus comprising: means for updating a lookaside table with a table entry having a source logical address and a destination logical address specified in a first host command, the lookaside table being stored in a control data memory; means for logically linking the table entry of the lookaside table with a corresponding entry of an L2P table stored in the control data memory; and means for accessing the table entry of the lookaside table and the corresponding entry of the L2P table to control a memory operation on data stored in a non-volatile memory.

[0010] Various aspects of the present disclosure provide improvements to data storage devices. For example, the process of handling garbage collection and host device input / output by the data storage device is optimized. The present disclosure can be embodied in various forms, including hardware or circuits controlled by software, firmware, or a combination thereof. The above invention content is only intended to give a general idea of ​​various aspects of the present disclosure, and does not limit the scope of the present disclosure in any way. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a block diagram illustrating a data storage system in which example embodiments may be practiced.

[0012] Figure 2 is a flow chart illustrating a file system defragmentation method according to an embodiment.

[0013] FIG. 3A to FIG. 3B is an example of a method that can be used according to an embodiment of the present invention. Figure 1 A block diagram of exemplary features of end-to-end data protection used in a data storage system.

[0014] Figure 4 is a flow chart illustrating a file system defragmentation method according to another embodiment.

[0015] Figure 5 Examples of embodiments that can be used in Figure 4 Lookaside table used in the file system defragmentation method.

[0016] Figure 6 is a flow chart illustrating a file system defragmentation method according to another embodiment. DETAILED DESCRIPTION

[0017] In the following description, many details are set forth, such as data storage device configuration, controller operation, etc., in order to provide an understanding of one or more aspects of the present disclosure. It will be apparent to those skilled in the art that these specific details are merely exemplary and are not intended to limit the scope of the present application. Specifically, the functions associated with the controller may be performed by hardware (e.g., analog or digital circuits), 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 circuit), or any other suitable means. The following description is intended only to give a general idea of ​​the various aspects of the present disclosure, without limiting the scope of the present disclosure in any way. In addition, it will be apparent to those skilled in the art that, although the present disclosure relates to NAND flash memory, the concepts discussed herein may be applicable to other types of solid-state memories, such as NOR, PCM ("phase change memory"), ReRAM, and the like.

[0018] NAND flash memory based SSDs read and write data in units of pages. In an exemplary SSD, 128 pages make up a single data block. Before any data can be written or programmed to the SSD, entire blocks of data that are no longer needed or valid may have to be erased. An internal SSD housekeeping operation known as "garbage collection" or "GC" is used to manage and maintain available storage space to handle the difference between the erase unit size (block) and the read / write unit size (page). When garbage collection is performed for a previously written block, the valid data pages are collected and moved to another block in the SSD so that the block containing the invalid data page can be completely erased.

[0019] Whenever a discontinuous logical block address (LBA) range is addressed by the host, a new input / output (I / O) command is transmitted to the data storage device for each discontinuous portion of the LBA range, which brings a corresponding processing overhead. Eventually, as the file system becomes increasingly fragmented, the accumulated processing overhead can become large enough to degrade overall SSD performance. In this context, the relevant fragmentation is not physical fragmentation, but rather the fragmentation of the file organization and / or structure in the file system. Therefore, in the case of an SSD, the operating system (host) can perform defragmentation to prevent the file system from reaching the system's maximum file system fragmentation tolerance.

[0020] The criteria (e.g., one or more thresholds) for determining when to issue a file system defragmentation command to the memory controller may vary depending on the specific operating system and / or file system requirements. For hard disk drives, physical fragmentation becomes detrimental faster than file system fragmentation. In contrast, for SSDs, file system fragmentation typically causes more significant performance degradation than physical fragmentation. Therefore, SSDs require different defragmentation methods than those used for hard disk drives.

[0021] At least some of the above-identified problems can be solved using at least some embodiments of the file system defragmentation methods and apparatus disclosed herein. For example, in various embodiments, the negative effects of file system fragmentation are mitigated by one or more of the following: (i) updating a logical-to-physical (L2P) table to change the association of a physical address of a user data segment from being associated with a source logical address to being associated with a destination logical address of a host defragmentation request without moving user data in flash memory; (ii) maintaining a backup table that replaces relevant portions of the L2P table for end-to-end data protection purposes; and (iii) performing physical data rearrangement corresponding to file system defragmentation only in response to certain triggering events.

[0022] Flash-based data storage devices (e.g., SSDs) use an L2P table to translate the logical address of an input / output (I / O) request into a corresponding flash memory physical address. The layer that performs the translation is called a flash translation layer (FTL). The controller of some data storage devices may have a random access memory (RAM) in which at least a portion of the L2P table may be stored.

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

[0024] In some embodiments, the data storage device 102 may be embedded within the host device 190. In some other embodiments, the data storage device 102 may be removable from the host device 190, such as being removably coupled to the host device 190 according to a removable universal serial bus (USB) configuration. In some embodiments, the data storage device 102 may be used as an embedded storage drive, such as a mobile embedded storage drive, an enterprise storage drive (ESD), a client storage device, a cloud storage drive, or other suitable data storage device.

[0025] like Figure 1 As shown in , 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 190. Such communication may include, among other things, sending data between the NVM 130 and the host device 190. The NVM 130 includes a storage die 170, which may include any type or any suitable combination of NAND flash memory devices, NOR flash memory devices, and other suitable non-volatile memory devices. The storage die 170 may be organized into channels, each of which is based on a corresponding bus, such as an 8-bit bus, that connects a corresponding subset of the storage die 170 to the controller 110. Individual storage die in the storage die 170 may also be organized into a hierarchy of planes, blocks, and pages. The NVM 130 and / or individual storage die in its storage die 170 may also include support circuitry ( Figure 1160). In an example embodiment, DRAM 150 is used to store L2P table 160, among other things.

[0026] The controller 110 includes components, such as circuitry, firmware, and software, that bridge the NVM 130 to the host device interface 104, where for greater clarity, Figure 1 Only some of the components are explicitly 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, Figure 1 (iii) DRAM controller 114; (iv) error correction code (ECC circuit or module 116; and (v) flash memory component interface ( Figure 1 In some embodiments, the controller 110 may further include a DRAM 150 or other volatile memory with similar functions in which the L2P table 160 is stored.

[0027] Processor 112 is configured to support, for example, some or all of the following operations: wear leveling, bad block management, data scrambling, error correction coding, garbage collection, trimming, address mapping, file system defragmentation, and other related operations. DRAM controller 114 serves as an electronic controller for DRAM 150. ECC entity 116 may generally include two submodules, wherein a first of the submodules operates a first ECC applied to data stored in NVM 130, and wherein a second of the submodules operates a different second ECC applied to data stored in DRAM 150, the data stored in the DRAM including data of L2P table 160 and other tables that may be stored in the DRAM (see, e.g., Figure 5 ).

[0028] The host device 190 may use a logical address to address data stored in the NVM 130. However, the data is stored at a physical address in the NVM 130. The L2P table 160 is used to map from a logical address used by the host device 190 to a physical address of data actually stored in the NVM 130. When the host device 190 requests to read data, the controller 110 may look up the physical address in 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 may update the L2P table 160 accordingly.

[0029] The master L2P table may be stored in NVM 130, but in order to be efficiently used or updated by controller 110, at least relevant portions of the master L2P table are stored in DRAM 150, such as in L2P table 160. When L2P table 160 is updated, the updates need to be written back to the master L2P table stored in NVM 130. During the design process of data storage device 102, it may be specified whether DRAM 150 will be designated to hold a copy of the entire master L2P table for the entire logical address space. The decision not to hold the entire master L2P table in DRAM 150 may be due to, for example, the limited size of DRAM 150. Similar design decisions may also be made for other tables that may be used instead of or in conjunction with L2P table 160 according to various embodiments.

[0030] For illustrative purposes and without any implicit limitation, some example implementations may be described below with reference to page-level L2P mapping. Based on the description provided, a person of ordinary skill in the relevant art will readily understand how to form and use other implementations, such as implementing block-level L2P mapping or other specific granularity L2P mapping.

[0031] For an example embodiment of NVM 130, with page-level L2P mapping, a physical address may include a channel number, a die number, a block number, and a page number. For a 4kB page size, a 32TB NVM 130 may require approximately 32GB of such L2P entries. With increased ECC overhead, a 40GB DRAM 150, for example, may accommodate this amount of L2P entries. This estimate of DRAM capacity is roughly linearly proportional to the data capacity of NVM 130.

[0032] although Figure 1 Controller 110 is shown connected to and employing DRAM 150, but alternative embodiments are possible. For example, in one such embodiment, to achieve similar functionality, controller 110 may employ a built-in cache memory, such as static random access memory (static RAM or SRAM), as part of the controller circuitry. In another embodiment, instead of DRAM 150, controller 110 may use a dedicated portion of NVM 130 as a storage device for L2P table 160.

[0033] Figure 22 is a flowchart illustrating a file system defragmentation method 200 according to an embodiment. For illustrative purposes and without any implicit limitation, the method 200 is described below as being triggered by a defragmentation command received by the controller 110 from the host device 190. However, in some embodiments, the method 200 may be triggered by other single commands or by a collection of two or more commands. For example, in one possible embodiment, the method 200 may be triggered by a copy command received by the controller 110 from the host device 190.

[0034] The method 200 includes the controller 110 receiving a defragmentation command from the host device 190 (at box 202). As indicated above, the host device 190 may issue such a defragmentation command, for example, to prevent the file system from reaching the host's maximum file system fragmentation tolerance or to achieve another purpose related to file system management. For example, the defragmentation command may specify a source range of logical addresses and a different destination range of logical addresses for a user data segment. A conventional response to such a command may typically involve physical data movement, such as moving from a physical address corresponding to the source range of logical addresses to a physical address corresponding to the destination range of logical addresses. In contrast, according to the method 200, the response of the data storage device 102 to such a command typically does not involve any physical data movement in the NVM 130, such as described in further detail below.

[0035] The method 200 includes the controller 110 accessing (at block 204) a source portion and a destination portion of the L2P table 160. The source portion of the L2P table 160 has a mapping of a source range of logical addresses specified in the defragmentation command received at block 202. The destination portion of the L2P table 160 has a mapping of a destination range of logical addresses specified in the defragmentation command received at block 202. In some cases, such as when the data segments do not occupy a contiguous range of logical addresses, the controller 110 may access (at block 204) corresponding multiple source and destination portions of the L2P table 160.

[0036] The method 200 includes the controller 110 updating (at block 206) a destination portion of the L2P table 160. The updating is performed based on the defragmentation command of block 202. In an example embodiment, the updating (at block 206) of the L2P table 160 includes updating (e.g., replacing) physical addresses associated with the destination range of logical addresses to specify therein physical addresses corresponding to the source range of logical addresses.

[0037] The method 200 includes the controller 110 updating the source portion of the L2P table 160 (at block 208). The update is performed based on the defragmentation command of block 202. In an example embodiment, the update of the L2P table 160 (at block 208) includes invalidating the L2P mapping of the source range of logical addresses. Such invalidation may be similar to the invalidation performed for an "erase" operation.

[0038] The method 200 includes the controller 110 refreshing the updated L2P portion (at block 210). In an example embodiment, the refresh operation includes synchronizing a corresponding portion of the master L2P table stored in the NVM 130 with the updated portion of the L2P table 160 stored in the DRAM 160. In various examples, after completing the synchronization operation, the controller 110 may or may not transmit an acknowledgement of the completion of executing the defragmentation command back to the host device 190.

[0039] The method 200 includes the controller 110 receiving (at block 212) a second command from the host device 190. For example, the second host command may be a read command corresponding to a destination range of logical addresses of the defragmentation command of block 202. In some cases, the second host command may be a different host command (different from the read command) corresponding to or referring to a destination range of logical addresses of the defragmentation command of block 202.

[0040] The method 200 includes the controller 110 accessing the L2P table 160 in response to the second host command (at block 214). More specifically, the controller 110 is operable to access (at block 214) an entry of the L2P table 160 corresponding to a range of logical addresses of the second host command received at block 212. The method 200 also includes the controller 110 extracting (at block 214) a physical address specified by the accessed entry of the L2P table 160. Note that the physical address extracted at block 214 will be the physical address resulting from the update performed at block 206. The method 200 also includes the controller 110 routing the second host command to the extracted physical address in the NVM 130 (at block 214).

[0041] In some embodiments, the data storage system 100 may support end-to-end data protection (E2EDP). E2EDP is a feature that extends error control to cover the entire data path from the host device 190 to the NVM 130 and from the NVM to the host device and ensures data integrity at multiple points along the data path. In various embodiments, E2EDP may use one or more of the following to identify errors occurring at various transmission points along the data path: L2P parity protection, host LBA embedding and read page checking, and various ECC techniques, such as cyclic redundancy checksum (CRC), Bose–Chaudhuri–Hocquenghem (BCH) encoding, and low-density parity check (LDPC) encoding.

[0042] FIG. 3A to FIG. 3B 1 is a block diagram illustrating host LBA embedding that can be used for E2EDP in data storage system 100 according to an embodiment. In this embodiment, when host device 190 writes data to data storage device 102, the data storage device is provided with Figure 3A 3. The data storage device 102 operates to attach the host LBA 304 as a tag to the data 302, for example by logically combining the two elements into a tagged data section 310. Figure 3B The marked data segment 310 is written to the physical address in the NVM 130. Then, the host LBA 304 and the physical address are recorded in the L2P table 160.

[0043] When the host device 190 issues a read command for the host LBA 304, the controller 110 looks in the L2P table 160 to determine which physical address contains the corresponding data 302. When the NVM 130 is accessed at that physical address, the entire tagged data segment 310 is read, thereby providing the LBA value of the tag 304. The latter LBA value is then compared to the LBA value in the L2P table 160 to ensure a match. This process of storing the LBA when writing data and then reading back the stored LBA and comparing the LBA to the entry stored in the L2P table 160 ensures that the data storage device 102 returns the correct data 302 when it is requested as part of the E2EDP feature.

[0044] Since the processing performed at blocks 206, 208 of method 200 may modify the contents of L2P table 160 without physically moving data, at least some embodiments of method 200 may be compatible with some specific implementations of the E2EDP feature. However, method 200 may be advantageously used with various SD / USB cards that do not require E2EDP, for example.

[0045] SD card is short for Secure Digital card, which is a type of removable memory card used to read and write data in various mobile electronic devices, cameras, video game consoles, set-top boxes, smart appliances and many other devices. For example, the Secure Digital High Capacity (SDHC) card supports up to 32GB of capacity and uses the FAT32 file system. The Secure Digital Extended Capacity (SDXC) format can store up to 2TB on the exFAT file system. The Secure Digital Ultra Capacity (SDUC) card can store up to 128TB per card using the exFAT file system. At least some of the available form factor options include SD, mini SD, micro SD, SDHC, mini SDHC, micro SDHC, SDXC, and micro SDXC form factors.

[0046] A USB card or drive is a removable data storage device equipped with a USB connector. USB drives are generally compatible with any system that provides a USB port, including Windows, Mac, and Linux computers. USB drives can have various data capacities, such as up to 1TB. Port connectors of USB Type A or Type C can be used. Various USB drives can be compatible with USB2, USB3, or USB4 specifications.

[0047] Figure 4 is a flow chart illustrating a file system defragmentation method 400 according to another embodiment. One possible embodiment of method 400 may be viewed as a modification of method 200. Another possible embodiment of method 400 may be a separate solution that is different and distinct from method 200. One or more features of method 400 facilitate making this method compatible with the E2EDP feature in general, and with the LBA tagging described above in particular.

[0048] For purposes of illustration and without any implicit limitation, method 400 is described below as being triggered by a defragmentation command received by controller 110 from host device 190. However, in some embodiments, method 400 may be triggered by other single commands or by a collection of two or more commands. For example, in one possible embodiment, method 400 may be triggered by a copy command received by controller 110 from host device 190.

[0049] Method 400 includes controller 110 receiving a defragmentation command from host device 190 (at block 402). The defragmentation command may specify a source range of logical addresses and a different destination range of logical addresses for a data sector. Similar to corresponding features of method 200, according to method 400, the response of data storage device 102 to the defragmentation command does not substantially involve any physical data rearrangement in NVM 130.

[0050] The method 400 includes the controller 110 updating the lookaside table (at block 404). In an example embodiment, the lookaside table may be stored in the DRAM 160 along with the L2P table 160. The update of the lookaside table is performed based on the defragmentation command of block 402.

[0051] Figure 5 4 is a diagram illustrating a lookaside table 500 that may be used in method 400 according to an embodiment. For purposes of illustration and without any implied limitation, lookaside table 500 is shown and described as having one entry. However, in many cases, lookaside table 500 may typically include more than one entry, where each of the entries is associated with Figure 5 is similar to the one illustrated in .

[0052] like Figure 5 , each entry of the lookaside table 500 includes four fields: an identifier field 502, a source logical address field 504, a destination logical address field 506, and a length field 508. The identifier (ID) field 502 has an index value that can be used to identify different entries of the table 500. For example, the different entries of the table 500 can be indexed sequentially in the order in which they were created based on different defragmentation commands received at different instances of block 402 of the method 400. The other fields (i.e., 504, 506, 508) of the corresponding entry of the table 500 are populated based on the parameters of the corresponding defragmentation command.

[0053] For example, the source logical address field 504 of the entry has the source logical address of the data segment in question, as specified in the corresponding defragmentation command. The destination logical address field 506 of the entry has the destination logical address of the data segment, as specified in the corresponding defragmentation command. The length field 508 of the entry has the length of the data segment, as specified in the corresponding defragmentation command. Figure 1 As shown in FIG. 5 , for purposes of illustration, the entry corresponding to ID=1 (in field 502) has exemplary values ​​in fields 504, 506, 508. These exemplary values ​​may correspond to a copy or defragmentation request for a 0x1000 page with source LBA 0x3000 and destination LBA 0x6000.

[0054] Return to reference Figure 4, the method 400 includes the controller 110 logically linking (at block 406) the corresponding entry of the lookaside table 500 with the L2P table 160. In an example embodiment, such logical linking may include (i) identifying entries having the same source LBA in the lookaside table 500 and the L2P table 160; and (ii) placing corresponding pointers in the identified entries of the lookaside table 500 pointing to the corresponding identified entries of the L2P table 160. Such logical linking may additionally or alternatively include configuring the controller 110 to treat the entry of the lookaside table 500 as a replacement for the linked entry of the L2P table 160.

[0055] The method 400 includes the controller 110 accessing (at block 408) both the lookaside table 500 and the L2P table 160 for related memory operations (e.g., read operations and E2EDP check operations). For example, after receiving a read request for a particular LBA from the host device 190, the controller 110 operates to access the lookaside table 500 before accessing the L2P table 160. When accessing the lookaside table 500 (at block 408), the controller 110 operates to determine whether the particular LBA exists among the values ​​stored in the destination logical address field 506 of the lookaside table. The controller 110 performs other actions (at block 408), such as described below. The specific other actions taken by the controller 110 at block 408 generally depend on the results of the above determination.

[0056] At block 408, when the particular LBA is found in field 506 of the lookaside table 500, the controller 110 operates to extract the physical address from the link entry of the L2P table 160. The controller 110 further operates to route the read operation to the extracted physical address (at block 408). After retrieving the corresponding tagged data segment 310 from the physical address, the controller 110 operates to perform an E2EDP check by comparing the LBA value of the tag 304 from the retrieved data segment 310 with the LBA value of the corresponding field 504 of the lookaside table 500 (at block 408). Alternatively, the controller 110 may be operable to perform the same E2EDP check by comparing the LBA value of the tag 304 with the LBA value of the corresponding entry from the L2P table 160.

[0057] At block 408, when a particular LBA is not found in field 506 of lookaside table 500, controller 110 operates to search and find the LBA in L2P table 160. Controller 110 also operates to extract the physical address associated with the LBA in L2P table 160 (at block 408). Next, controller 110 operates to route the read operation to the extracted physical address (at block 408). After retrieving the corresponding tagged data segment 310 from the physical address, controller 110 operates to perform an E2EDP check by comparing the LBA value of tag 304 with the LBA value of the used entry of L2P table 160 (at block 408).

[0058] In some alternative implementations of method 400, L2P table 160 may be accessed first (at block 408). In such implementations, depending on the result of the E2EDP check, lookaside table 500 may or may not be accessed at block 408. More specifically, when the E2EDP check succeeds, lookaside table 500 is not accessed. However, when the E2EDP check fails, lookaside table 500 is accessed.

[0059] Figure 6 6 is a flowchart illustrating a file system defragmentation method 600 according to another embodiment. The difference between method 600 and methods 200 and 400 is that method 600 involves physically moving or rearranging data in NVM 130, as described in more detail below. Similar to method 400, method 600 has one or more features compatible with E2EDP and LBA tags. For illustrative purposes and without any implicit limitation, method 600 is described below as being triggered by a defragmentation command received by controller 110 from host device 190. However, in some embodiments, method 600 may be triggered by other single commands or by a collection of two or more commands. For example, in one possible embodiment, method 600 may be triggered by a copy command received by controller 110 from host device 190.

[0060] Method 600 includes controller 110 receiving a defragmentation command from host device 190 at block 602. The defragmentation command may specify a source range of logical addresses and a different destination range of logical addresses for a data sector. In some embodiments, block 602 may be implemented similarly to block 402 of method 400.

[0061] Method 600 includes controller 110 updating a corresponding lookaside table (at block 604). In an example embodiment, the lookaside table may be stored in DRAM 160 along with L2P table 160. The update to the lookaside table is performed based on the defragmentation command of block 602. In at least some embodiments, block 604 may be implemented similarly to block 404 of method 400. The lookaside table used in method 600 may be similar to lookaside table 500 ( Figure 5 ).

[0062] The method 600 includes the controller 110 logically linking (at block 606) corresponding entries of the lookaside table 500 with the L2P table 160. In an example embodiment, such logical linking may include (i) identifying entries having the same source LBA in the lookaside table 500 and the L2P table 160; and (ii) placing corresponding pointers in the identified entries of the lookaside table 500 pointing to the corresponding identified entries of the L2P table 160. Such logical linking may additionally or alternatively include configuring the controller 110 to treat the entries of the lookaside table 500 as replacing the linked entries of the L2P table 160.

[0063] The method 600 includes the controller 110 detecting a triggering event to physically move or reorder data in the NVM 130 (at block 608). In some cases, the triggering event may be the controller 110 receiving a read command from the host device 190, wherein the LBA specified in the received read command is one of the LBA values ​​in the destination logical address field 506 of the lookaside table 500. In some other cases, the triggering event may be the controller 110 receiving a write command from the host device 190, wherein the LBA specified in the received write command is one of the LBA values ​​in the source logical address field 504 of the lookaside table 500. In still other cases, the triggering event may be the start of a GC operation involving an entry of the lookaside table 500. In still other cases, the triggering event may be the controller 110 receiving a write command for any LBA (e.g., a source LBA, a destination LBA, or any other LBA that the controller needs to assume that the host device 190 has overwritten previously written data).

[0064] The method 600 includes the controller 110 causing the NVM 130 to physically move (e.g., copy) data associated with the logical address involved in the triggering event to a different physical address (at block 610). For example, when the triggering event of block 608 is a read command, the controller 110 issues a control command to the NVM 130 to cause the data associated with the corresponding destination logical address field 506 of the lookaside table 500 to be copied to a different physical address (at block 610). The controller 110 also issues a synchronous read command for the same data (at block 610). When the triggering event of block 608 is a write command, the controller 110 issues a control command to the NVM 130 to cause the data associated with the source logical address field 504 of the lookaside table 500 to be copied to a different physical address (at block 610). The controller 110 also executes a write command on the incoming data (at block 610). When the triggering event of block 608 is the start of a GC operation, the controller 110 issues a control command to the NVM 130 to cause valid data to be erased in the physical data block to be copied to a different physical address (at block 610 ).

[0065] The method 600 includes the controller 110 updating the lookaside table 500 and the L2P table 160 (at block 612). For example, at block 612, entries of the lookaside table 500 for which corresponding data has been copied to a different physical address at block 610 may be deleted. The L2P table 160 is updated at block 612, wherein the entries properly list the logical addresses and physical addresses of the data copied at block 610.

[0066] Various embodiments of method 600 may be advantageous because only relevant data (i.e., data involved in the triggering event of block 608) is physically copied, while other data is logically managed by lookaside table 500. Another benefit of method 600 is that when any failure of an LBA occurs before a corresponding read operation, the corresponding update of table 500 and / or L2P table 160 may be performed without any I / O transfer to NVM 130. At least these features of method 600 advantageously enable improved I / O performance of data storage system 100.

[0067] For the processes, systems, methods, heuristics, etc. described herein, it should be understood that although the steps of such processes, etc. have been described as being performed according to a certain ordered sequence, such processes can be practiced with the steps performed in an order other than the order described herein. It should also be understood that certain steps can be performed simultaneously, other steps can be added, or certain steps described herein can be omitted. In other words, the description of the processes herein is provided for the purpose of illustrating certain specific implementations and should in no way be construed as limiting the claims.

[0068] Therefore, it should be understood that the above description is intended to be exemplary and not restrictive. Upon reading the above description, many embodiments and applications other than the examples provided will be apparent. The scope should not be determined with reference to the above description, but should be determined with reference to the attached claims together with the full range of equivalents to which such claims are entitled. It is anticipated and intended that the technology discussed herein will undergo future development, and the disclosed systems and methods will be incorporated into such future implementations. In short, it should be understood that the present application is capable of modification and variation.

[0069] All terms used in the claims are intended to be given their broadest reasonable constructions and their ordinary meanings as understood by those familiar with the technology described herein, unless expressly indicated to the contrary herein. In particular, use of singular articles such as "a," "an," "the," and the like should be understood to recite one or more of the indicated elements, unless a claim recites an express limitation to the contrary.

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

[0071] The use of figure numbers and / or figure reference labels (if any) in the claims is intended to identify one or more possible embodiments of the claimed subject matter to facilitate the interpretation of the claims. Such use should not be construed as necessarily limiting the scope of the claim to the embodiments shown in the corresponding figures.

[0072] Although elements of the following method claims are recited in a specific order by corresponding labels (if any), these elements are not necessarily intended to be limited to implementation in this specific order unless the claim recitation otherwise implies a specific order for implementing some or all of these elements.

[0073] Reference herein to "one 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 present disclosure. The phrase "in one embodiment" appearing in various places in the specification is not necessarily all referring to the same embodiment, nor are separate or alternative embodiments necessarily mutually exclusive of other embodiments. This applies to the term "embodiment".

[0074] Unless otherwise specified herein, the use of ordinal adjectives "first," "second," "third," etc. to refer to one of multiple similar objects merely indicates that different instances of such similar objects are referred to, and is not intended to imply that the similar objects so referred to must be in a corresponding order or sequence, whether in time, space, order, or any other aspect.

[0075] Unless otherwise specified herein, in addition to the ordinary meaning, the conjunction "if" may also be interpreted or alternatively interpreted as meaning "when" or "after" or "in response to determining" or "in response to detecting", and this interpretation may depend on the corresponding specific context. For example, the phrase "if it is determined" or "if [the stated condition] is detected" may be interpreted to mean "after determining" or "in response to determining", or "after detecting [the stated condition or event]" or "in response to detecting [the stated condition or event]."

[0076] And for the purposes of this description, the terms "couple", "coupling", "coupled", "connect", "connecting", "connected" refer to any means known in the art or later developed to allow energy to be transferred between two or more elements, and encompass the intervening of one or more additional elements, although not required. Conversely, the terms "directly coupled", "directly connected", etc., mean that there are no such additional elements.

[0077] The embodiments described are to be considered in all respects as illustrative only and not restrictive. Specifically, the scope of the present disclosure is indicated herein by the appended claims rather than the description and drawings. All changes within the meaning and range of equivalence of the claims are included within their scope.

[0078] The functions of the various elements shown in the figure (including any functional blocks marked as "processors" and / or "controllers") can be provided by using dedicated hardware and hardware capable of executing software associated with appropriate software. When provided by a processor, the function can be provided by a single dedicated processor, by a single shared processor, or by multiple individual processors, some of which can be shared. In addition, the explicit use of the term "processor" or "controller" should not be interpreted as referring exclusively to hardware capable of executing software, and may implicitly include, but are not limited to, digital signal processor (DSP) hardware, network processors, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), read-only memories (ROMs), random access memories (RAMs), and non-volatile memory devices for storing software. Other hardware that is traditional and / or customized may also be included. Similarly, any switch shown in the figure is conceptual only. Its function can be performed by the operation of program logic, by dedicated logic, by the interaction of program control with dedicated logic, or even manually, and a specific technique can be selected by the implementer, as more specifically understood from the context.

[0079] As used in this application, the term "circuitry" may refer to one or more or all of the following: (a) hardware circuitry implementations only (such as implementations in analog and / or digital circuitry only); (B) combinations of hardware circuitry and software, such as (if applicable): (i) combinations of analog and / or digital hardware circuitry and software / firmware; and (ii) hardware processors (including digital signal processors), software, and any portion of memory) with software that cooperate to enable a device (such as a mobile phone or server) to perform various functions; and (c) hardware circuitry and / or processors, such as microprocessors or portions of microprocessors, that require software (e.g., firmware) to operate, but that software may not be present when the software is not required for operation. This definition of circuitry applies to all uses of this term in this application, including in any claims. By way of further example, as used in this application, the term circuitry also encompasses implementations of hardware circuitry or processor (or multiple processors) only, or portions of hardware circuitry or processors, and their (or their) accompanying software and / or firmware. The term circuitry also covers (for example and if applicable to a particular claim element) a baseband integrated circuit or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular network device, or other computing or networking equipment.

[0080] The "Summary" in this specification is intended to introduce some example embodiments, wherein additional embodiments are described in the "Detailed Description" and / or with reference to one or more figures. The "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.

[0081] The "Abstract of the Description" is provided to allow the reader to quickly determine the nature of the technical disclosure. It should be understood that the content submitted is not used to interpret or limit the scope or meaning of the claims. In addition, it can be seen in the aforementioned "Detailed Description" that various features are grouped together in various embodiments for the purpose of simplifying the present disclosure. This method of disclosure should not be interpreted as reflecting such an intention: the claimed embodiments require more features than those explicitly stated in each claim. On the contrary, as reflected in the following claims, the subject matter of the invention lies in less than all the features of a single disclosed embodiment. Therefore, the following claims are hereby incorporated into the "Detailed Description", with each claim independently serving as a separately claimed subject matter.

Claims

1. A data storage device, comprising: A non-volatile memory, wherein the non-volatile memory is used to store data; a second memory, the second memory being used to store a logical-to-physical (L2P) table and a lookaside table; and a controller coupled to the nonvolatile memory and the second memory and configured to: responsive to a first host command having a source logical address and a destination logical address, updating the lookaside table with a table entry having the source logical address and the destination logical address; logically linking the table entry of the lookaside table with a corresponding entry of the L2P table; as well as The table entry of the lookaside table and the corresponding entry of the L2P table are accessed to control memory operations on the data in the non-volatile memory. 2 . The data storage device of claim 1 , wherein the first host command is a defragmentation command or a copy command. 3 . The data storage device of claim 1 , wherein the memory operation is performed in response to a second host command, the second host command being a read command for the destination logical address. 4 . The data storage device of claim 1 , wherein the memory operation is performed in response to a second host command, the second host command being a write command to the source logical address.

5. The data storage device of claim 1, wherein the memory operation is garbage collection in the non-volatile memory.

6. The data storage device according to claim 1, wherein the data storage device is configured to perform end-to-end data protection on the data using at least logical address tags; and The non-volatile memory stores a section of the data marked with the source logical address.

7. The data storage device of claim 1 , wherein in response to a host read command for the destination logical address, the controller is configured to: extracting a physical address from the corresponding entry of the L2P table; and The host read operation is routed to the physical address.

8. A data storage device according to claim 1, wherein in response to a trigger event, the controller is also configured to cause the non-volatile memory to generate a copy of a segment of the data located in the non-volatile memory at a physical address associated with the source logical address in the L2P table at a different physical address in the non-volatile memory. 9 . The data storage device of claim 8 , wherein the controller is further configured to update the L2P table to have an entry corresponding to the copy.

10. The data storage device of claim 9, wherein the controller is further configured to delete the table entry in the lookaside table.

11. The data storage device of claim 8, wherein the trigger event is later in time than the first host command.

12. A method performed by a data storage device receiving a command from a host device, the method comprising: updating, by the controller, a lookaside table with a table entry having a source logical address and a destination logical address specified in the first host command, the lookaside table being stored in a control data memory of the data storage device; logically linking, by the controller, the table entry of the lookaside table with a corresponding entry of a logical-to-physical (L2P) table stored in the control data memory; as well as The table entry of the lookaside table and the corresponding entry of the L2P table are accessed by the controller to control memory operations on data stored in a non-volatile memory of the data storage device.

13. The method of claim 12, wherein the first host command is a defragmentation command or a copy command.

14. The method of claim 12, wherein the memory operation is performed in response to a second host command, the second host command being a read command for the destination logical address or a write command for the source logical address.

15. The method of claim 12, wherein the memory operation is garbage collection in the non-volatile memory.

16. The method according to claim 12, wherein the data storage device is configured to perform end-to-end data protection on the data using at least logical address tags; and The non-volatile memory stores a section of the data marked with the source logical address.

17. The method according to claim 12, further comprising: In response to a host read command for the destination logical address, extracting, by the controller, a physical address from the corresponding entry of the L2P table; as well as The host read operation is routed to the physical address by the controller.

18. The method according to claim 12, further comprising: In response to a triggering event, the controller causes the nonvolatile memory to generate, at a different physical address in the nonvolatile memory, a copy of the segment of the data located in the nonvolatile memory at the physical address associated with the source logical address in the L2P table.

19. The method according to claim 18, further comprising: updating, by the controller, the L2P table to have an entry corresponding to the copy; as well as deleting the table entry in the backup table by the controller; and The trigger event is later in time than the first host command.

20. An apparatus for receiving a command from a host device, the apparatus comprising: means for updating a lookaside table stored in a control data memory with a table entry having a source logical address and a destination logical address specified in the first host command; means for logically linking said table entry of said lookaside table with a corresponding entry of a logical-to-physical (L2P) table stored in said control data memory; as well as Means for accessing the table entry of the lookaside table and the corresponding entry of the L2P table to control memory operations on data stored in non-volatile memory.

Images