Logic-to-physical mapping for defragmentation of host file systems in data storage devices

Abstract

A data storage device having a flash translation layer configured to process file system defragmentation in a manner that substantially avoids physical data movement in the flash. In an example embodiment, a memory controller operates to update its logical-to-physical table to change an 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 a flash memory. This update may reduce the number of instances in which the host addresses the non-contiguous logical address range, which results in a beneficial reduction in the number of input / output commands sent to the data storage device and the associated processing overhead.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] For all purposes, this application claims the benefit of the entire contents of U.S. non-provisional application No. 17 / 865,660, filed on July 15, 2022, and entitled “LOGICAL-TO-PHYSICAL MAPPING FOR DEFRAGMENTATION OF HOST FILE SYSTEM IN A DATA STORAGE DEVICE,” and is hereby incorporated by reference into this application. 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 can help promote a better understanding of the present disclosure. Therefore, the statements in this section should be read from this perspective and should not be understood as an admission that there is something in the prior art or something 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 non-sequentially. File system fragmentation can negatively impact data access time 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 multiple seeks, it is slower than reading or writing a contiguous file. Fragmentation can be remedied by reorganizing files and free space into contiguous areas, a process often referred to as "defragmentation." Since solid-state drives (SSDs) do not seek, defragmentation is generally not recommended for SSDs. However, fragmentation still occurs in SSDs, which can adversely affect the overall performance of the SSD. Summary of the invention

[0006] Various embodiments of a data storage device having a flash translation layer are disclosed herein, the data storage device being configured to handle file system defragmentation in a manner that substantially avoids physical data movement in flash memory. In an example embodiment, a memory controller operates to update its logical-to-physical table (L2P) 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 physically rearranging the user data in the flash memory. Such an update can reduce the number of instances in which a host addresses a non-contiguous logical address range, which results in a beneficial reduction in the number of input / output commands sent to the data storage device and the associated processing overhead.

[0007] In some embodiments, the memory controller may also maintain a lookaside table that replaces relevant portions of the logical-to-physical table. Entries of the lookaside table are configured to track source and destination addresses of host defragmentation requests and are logically linked to corresponding entries of the logical-to-physical table, so that end-to-end data protection including the use of logical address tags for user data can be supported by logical means without physically rearranging the user data in the flash memory.

[0008] According to an example embodiment, a data storage device receiving a command from a host device is provided, the data storage device comprising: a non-volatile memory; a control data memory for storing one or more tables including an L2P table; and a controller coupled to the non-volatile memory and the control data memory and configured to: in response to a first host command having a source logical address and a destination logical address, update one or more entries in the one or more tables to associate a physical address with the destination logical address, which physical address was associated with the source logical address in the L2P table before the update; and in response to a second host command having a destination logical address, access at least one of the one or more entries to route the second host command to the physical address of the non-volatile memory. In various examples, the control data memory can be a dedicated partition (e.g., a control block or portion) of a volatile memory or a non-volatile memory associated with the controller.

[0009] According to another example embodiment, a method performed by a data storage device that receives a command from a host device is provided, the method comprising: in response to a first host command having a source logical address and a destination logical address, updating, with a controller, one or more entries in one or more tables stored in a control data memory to associate a physical address with the destination logical address, the physical address being associated with the source logical address in one or more tables before the update, the one or more tables including an L2P table; and in response to a second host command having a destination logical address, accessing, with the controller, at least one of the one or more entries to route the second host command to a physical address of a non-volatile memory.

[0010] According to yet another example embodiment, there is provided an apparatus for receiving a command from a host device, the apparatus comprising: a device for updating, using a controller, one or more entries in one or more tables stored in a control data memory to associate a physical address with a destination logical address, the physical address being associated with a source logical address in one or more tables before the update, the one or more tables including an L2P table, the device for updating being executed in response to a first host command having a source logical address and a destination logical address; and a device for accessing, using the controller, at least one of the one or more entries to route a second host command having a destination logical address to a physical address of a non-volatile memory, the device for accessing being executed in response to the second host command.

[0011] Various aspects of the present disclosure provide improvements to data storage devices. For example, the process of garbage collection and host device input / output handled 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 intended only to give a general idea of ​​various aspects of the present disclosure and is not intended to limit the scope of the present disclosure in any way. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0014] FIG. 3A to FIG. 3B It is shown that according to the embodiment, Figure 1 Block diagram of example features of end-to-end data protection used in a data storage system.

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

[0016] Figure 5 It is shown that according to the embodiment, Figure 4 Lookaside table used in the file system defragmentation method.

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

[0018] 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.

[0019] NAND flash-based SSDs read and write data in units called pages. In an example 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 called "garbage collection" or "GC" is used to manage and maintain available storage space, dealing with the difference between the erase unit size (block) and the read / write unit size (page). When a previously written block becomes the target of garbage collection, the valid data pages are gathered and moved to another block in the SSD so that the block containing the invalid data pages can be completely erased.

[0020] Whenever a non-contiguous logical block address (LBA) range is addressed by the host, a new input / output (I / O) command is sent to the data storage device for each non-contiguous portion of the LBA range, which results in a corresponding processing overhead. Eventually, as the file system becomes increasingly fragmented, the accumulated processing overhead may become large enough to degrade overall SSD performance. Here, the relevant fragmentation is not physical fragmentation, but rather fragmentation of the file organization and / or structure in the file system. Therefore, for SSDs, the operating system (host) may perform defragmentation to prevent the file system from reaching the system's maximum file system fragmentation tolerance.

[0021] Depending on the specific operating system and / or file system requirements, the criteria (e.g., one or more thresholds) used to determine when to issue a file system defragmentation command to the memory controller may vary. For hard drives, physical fragmentation becomes detrimental more quickly than file system fragmentation. In contrast, for SSDs, file system fragmentation typically contributes to performance degradation more significantly than physical fragmentation. Therefore, SSDs require different defragmentation methods than defragmentation for hard drives.

[0022] At least some of the above-mentioned problems can be solved using at least some embodiments of the file system defragmentation method and apparatus disclosed herein. For example, in various embodiments, the adverse 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.

[0023] 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 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) that may be used to store at least a portion of the L2P table therein.

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

[0025] In some embodiments, the data storage device 102 can be embedded within the host device 190. In some other embodiments, the data storage device 102 can be removable from the host device 190, for example, can be removably coupled to the host device 190 according to a removable universal serial bus (USB) configuration. In some embodiments, the data storage device 102 can be used as an embedded storage drive (e.g., a removable embedded storage drive), an enterprise storage drive (ESD), a client storage device or cloud storage drive, or other suitable data storage device.

[0026] like Figure 1As shown, 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, data transfer between the NVM 130 and the host device 190. The NVM 130 includes a memory 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 memory die 170 may be organized into channels, each of which is based on a corresponding bus that connects a corresponding subset of the memory die 170 to the controller 110, for example, an 8-bit bus. The individual memory die in the memory die 170 may be further organized into a hierarchy of planes, blocks, and pages. The NVM 130 and / or the individual memory die in its memory die 170 may also include support circuits ( Figure 1 160). In an exemplary embodiment, DRAM 150 is used to store L2P table 160, among other things.

[0027] The controller 110 includes components, such as circuitry, firmware, and software, that bridge the NVM 130 to the host-device interface 104, and for greater clarity, is described in detail in the accompanying drawings. 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, in FIG. 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.

[0028] 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, pruning, address mapping, file system defragmentation, and other related operations. DRAM controller 114 operates as an electronic controller for DRAM 150. ECC entity 116 may generally include two submodules, wherein a first submodule operates a first ECC applied to data stored in NVM 130, and a second submodule operates a different second ECC applied to data stored in DRAM 150, including L2P table 160 and data of other tables that may be stored therein (e.g., see Figure 5 ).

[0029] 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 the logical address used by the host device 190 to the physical address where the data is 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.

[0030] The master L2P table may be stored in NVM 130, but in order to be effectively used or updated by controller 110, at least relevant portions of the master L2P table are stored in DRAM 150, such as 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. According to various embodiments, similar design decisions may also be made with respect to other tables that may be used in place of or in conjunction with L2P table 160.

[0031] For purposes of illustration and without any implicit limitation, some example implementations may be described below with reference to page-level L2P mapping. Based on the description provided, one of ordinary skill in the relevant art will readily understand how to make and use other implementations, for example, to implement block-level L2P mapping or other specific granularity of L2P mapping.

[0032] 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 4-kB page size, a 32-TB NVM 130 may require approximately 32GB of such L2P entries. With the addition of ECC overhead, this amount of L2P entries can be accommodated by, for example, a 40-GB DRAM 150. This estimate of DRAM capacity is approximately linearly proportional to the data capacity of NVM 130.

[0033] although Figure 1 Controller 110 is shown connected to and employing DRAM 150, but alternative embodiments are possible. For example, in one such embodiment, 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 for similar functionality. In another embodiment, instead of DRAM 150, controller 110 may use a dedicated portion of NVM 130 as storage for L2P table 160.

[0034] Figure 2 is a flow chart 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.

[0035] The method 200 includes the controller 110 receiving a defragmentation command from the host device 190 (at block 202). As described above, the host device 190, the host device may issue such a defragmentation command, for example, to prevent the file system from reaching the host's maximum file system fragmentation tolerance or for 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 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, the response of the data storage device 102 to such a command according to the method 200 typically does not involve any physical data movement in the NVM 130, for example, as described in further detail below.

[0036] The method 200 includes the controller 110 accessing (at block 204) source and destination portions 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 sectors 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.

[0037] 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) a physical address associated with a destination range of logical addresses to specify therein a physical address corresponding to a source range of logical addresses.

[0038] 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. This invalidation may be similar to the invalidation performed for an "erase" operation.

[0039] The method 200 includes the controller 110 flushing the updated L2P portion (at block 210). In an example embodiment, the flush 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 the synchronization operation is completed, the controller 110 may or may not send back to the host device 190 an acknowledgement of the completed execution of the defragmentation command.

[0040] 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 (different from the read) host command corresponding to or referring to a destination range of logical addresses of the defragmentation command of block 202.

[0041] 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 the logical address range of the second host command received at block 212. The method 200 also includes the controller 110 retrieving (at block 214) a physical address specified by the accessed entry of the L2P table 160. Note that the physical address retrieved at block 214 will be a 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 retrieved physical address in the NVM 130 (at block 214).

[0042] In some embodiments, the data storage system 100 can 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 back and ensures data integrity at multiple points along the data path. In various embodiments, E2EDP can use one or more of the following to identify errors occurring at various transfer 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.

[0043] FIG. 3A to FIG. 3B 1 is a block diagram illustrating a host-LBA embedding of an E2EDP that can be used in a data storage system 100 according to an embodiment. In this embodiment, when a host device 190 writes data to a data storage device 102, it provides the host device 190 with a host-LBA embedding. Figure 3A 3. The data storage device 102 is illustratively shown as two separate elements: (i) host / user data 302 to be written, and (ii) an LBA 304 associated with the data. The data storage device 102 operates to attach the host LBA 304 as a tag along with the data 302, such as by logically joining the two elements into a tag data section 310, such as Figure 3B The tag data section 310 is written to the physical address in the NVM 130 . The host LBA 304 and the physical address are then recorded in the L2P table 160 .

[0044] When a read command is issued by the host device 190 for a host LBA 304, the controller 110 looks in the L2P table 160 to determine which physical addresses contain the corresponding data 302. When the NVM 130 is accessed at that physical address, the entire tag data section 310 is read, providing the LBA value of the tag 304. This 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 data is written, then reading back the stored LBA and comparing it to the entry stored in the L2P table 160, as part of the E2EDP feature, ensures that the data storage device 102 returns the correct data 302 when requested.

[0045] Since the processing implemented 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 incompatible with some specific implementations of the E2EDP feature. However, method 200 may be beneficially used, for example, with various SD / USB cards for which E2EDP is not necessary.

[0046] An SD card (short for Secure Digital card) is a type of removable memory card used to read and write data in a variety of 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, miniSD, microSD, SDHC, miniSDHC, microSDHC, SDXC, and microSDXC form factors.

[0047] 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. There is a wide range of data capacities available for USB drives, such as up to 1TB capacity. Either USB Type A or Type C port connectors may be used. Various USB drives may be compatible with USB2, USB3, or USB4 specifications.

[0048] Figure 4is 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 stand-alone solution that is different and distinct from method 200. One or more features of method 400 beneficially render the method compatible with the E2EDP feature in general, and with the LBA tags described above in particular.

[0049] 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.

[0050] 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, a response of data storage device 102 to a defragmentation command according to method 400 does not substantially involve any physical data rearrangement in NVM 130.

[0051] 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 to the lookaside table is performed based on the defragmentation command of block 402.

[0052] 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 implicit 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, each of which is similar to Figure 5 An entry shown in .

[0053] like Figure 5, each entry of the backup 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, different entries of the table 500 can be indexed consecutively in the order in which they were created based on different defragmentation commands received at different instances of the 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.

[0054] 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, fields 504, 506, 508 corresponding to the entry with ID=1 (in field 502) have example values ​​therein for purposes of illustration. These example values ​​may correspond to a copy or defragmentation request for a 0x1000 page with a source LBA 0x3000 and a destination LBA 0x6000.

[0055] Return to reference Figure 4 , the method 400 includes the controller 110 logically linking corresponding entries of the lookaside table 500 and the L2P table 160 (at block 406). In an example embodiment, such logical linking may include (i) identifying entries in the lookaside table 500 and the L2P table 160 that have the same source LBA, and (ii) placing corresponding pointers in the identified entries of the lookaside table 500 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.

[0056] The method 400 includes the controller 110 accessing (at box 408) both the lookaside table 500 and the L2P table 160 for related memory operations, e.g., with respect to read operations and E2EDP check operations. For example, upon 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 box 408), the controller 110 operates to determine whether the particular LBA is present in the value stored in the destination logical address field 506 of the lookaside table. The controller 110 performs further actions (at box 408), e.g., as described below. The specific further actions taken by the controller 110 at box 408 generally depend on the results of the above determination.

[0057] At block 408, when the particular LBA is found in field 506 of the lookaside table 500, the controller 110 operates to retrieve the physical address from the link entry of the L2P table 160. The controller 110 further operates to route the read operation to the retrieved physical address (at block 408). After retrieving the corresponding tag 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.

[0058] 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 further operates to obtain a physical address associated with the LBA in L2P table 160 (at block 408). Controller 110 then operates to route the read operation to the obtained physical address (at block 408). After retrieving the corresponding tag 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 from L2P table 160 (at block 408).

[0059] In some alternative embodiments of method 400, L2P table 160 may be accessed first (at block 408). In such embodiments, 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.

[0060] Figure 6 6 is a flowchart illustrating a file system defragmentation method 600 according to yet another embodiment. Method 600 differs from methods 200 and 400 in that method 600 involves physical movement or rearrangement of 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.

[0061] 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 segment. In some embodiments, block 602 may be implemented similarly to block 402 of method 400.

[0062] Method 600 includes controller 110 updating a corresponding lookaside table (at block 604). In one 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 ).

[0063] The method 600 includes the controller 110 logically linking corresponding entries of the lookaside table 500 and the L2P table 160 (at block 606). In an example embodiment, such logical linking may include (i) identifying entries in the lookaside table 500 and the L2P table 160 that have the same source LBA, and (ii) placing corresponding pointers in the identified entries of the lookaside table 500 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.

[0064] The method 600 includes the controller 110 detecting a triggering event for a physical move or rearrangement of 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, for example, for a source LBA, a destination LBA, or any other LBA where the controller needs to assume that the host device 190 has overwritten data previously written there.

[0065] 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 so that the data associated with the corresponding destination logical address field 506 of the lookaside table 500 is 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 so that the data associated with the source logical address field 504 of the lookaside table 500 is copied to a different physical address (at block 610). The controller 110 also executes a write command for 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 so that valid data in the physical data block to be erased is copied to a different physical address (at block 610 ).

[0066] 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, an entry of the lookaside table 500 may be deleted whose corresponding data was copied to a different physical address at block 610. At block 612, the L2P table 160 is updated with an entry that correctly lists the logical address and physical address of the data that was copied at block 610.

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

[0068] 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.

[0069] 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.

[0070] 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.

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

[0072] The use of figure numbers and / or reference numerals in the claims, if any, is intended to identify one or more possible embodiments of the claimed subject matter to facilitate interpretation of the claims. Such use should not be interpreted as necessarily limiting the scope of those claims to the embodiments shown in the corresponding drawings.

[0073] Although elements in the following method claims, if any, are recited in a specific sequence with corresponding labels, those elements are not necessarily intended to be limited to being implemented in that specific sequence unless the claim recitation implies a specific sequence for implementing some or all of those elements.

[0074] References to "one embodiment" or "embodiment" herein mean that a particular feature, structure, or characteristic described in conjunction 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 this specification does not necessarily refer to the same embodiment, nor is it necessarily a separate or alternative embodiment that is mutually exclusive of other embodiments. The same applies to the term "specific implementation".

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

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

[0077] Also for the purposes of this specification, the terms "coupled", "connected" refer to any means known in the art or later developed in which energy is allowed to be transferred between two or more elements, and the insertion of one or more additional elements is contemplated, although not required. In contrast, the terms "directly coupled", "directly connected", etc. imply the absence of such additional elements.

[0078] The embodiments described are to be considered in all respects as merely illustrative and non-restrictive. In particular, the scope of the present disclosure is indicated by the appended claims rather than the description and drawings herein. All changes within the meaning and scope of the equivalents of the claims are included within their scope.

[0079] The functions of the various elements shown in the drawings, 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 exclusively referring to hardware capable of executing software, but may implicitly include, but 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 memories for storing software. Other hardware that is conventional and / or customized may also be included. Similarly, any switches shown in the figure are conceptual only. Their functions can be performed by the operation of program logic, by dedicated logic, by the interaction of program control and dedicated logic, or even manually, and specific techniques can be selected by the implementer, as more specifically understood from the context.

[0080] As used in this application, the term "circuitry" may refer to one or more or all of the following: (a) a hardware circuit implementation only (e.g., an implementation in analog and / or digital circuitry only); (b) a combination of hardware circuitry and software, such as, where applicable: (i) a combination of analog and / or digital hardware circuitry and software / firmware, and (ii) a hardware processor with software (including a digital signal processor), any portion of software and memory that work together to enable a device such as a mobile phone or server to perform various functions); and (c) a hardware circuit and / or processor, such as a microprocessor or a portion of a microprocessor, that requires software (e.g., firmware This definition of circuitry applies to all uses of the term in this application, including in any claims. As another example, as used in this application, the term circuitry also covers a specific implementation of only a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. For example and if applicable to a particular claim element, the term circuitry also covers 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 network device.

[0081] The Summary of the Invention in this specification is intended to introduce some example embodiments, and additional embodiments are described in the Detailed Description and / or with reference to one or more figures. The Summary of the Invention is not intended to identify essential elements or features of the subject matter protected by the claims, nor is it intended to limit the scope of the subject matter protected by the claims.

[0082] 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, in the aforementioned "Detailed Description", it can be seen 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 for receiving a command from a host device, the data storage device comprising: Non-volatile memory; a control data store for storing one or more tables including a logical-to-physical (L2P) table; and a controller coupled to the non-volatile memory and the control data memory, the controller being configured to: responsive to a first host command having a source logical address and a destination logical address, updating one or more entries in the one or more tables to associate a physical address with the destination logical address that was associated in the L2P table with the source logical address prior to the updating; as well as In response to a second host command having the destination logical address, at least one of the one or more entries is accessed to route the second host command to the physical address of the non-volatile memory.

2. The data storage device according to claim 1, wherein: The first host command is a defragmentation command or a copy command.

3. The data storage device according to claim 1, wherein: The second host command is a read command.

4. The data storage device according to claim 1, wherein: In response to the first host command and the second host command, no physical movement of user data is performed in the non-volatile memory.

5. The data storage device according to claim 1, wherein: The controller is configured to perform the updating at least by invalidating the source logical address in the L2P table.

6. The data storage device according to claim 1, wherein: The one or more tables include a fallback table.

7. The data storage device according to claim 6, wherein: The controller is configured to perform the updating at least by generating a table entry in the lookaside table having the source logical address and the destination logical address.

8. The data storage device according to claim 7, wherein: The controller is further configured to perform the updating at least by logically linking a table entry of the lookaside table with a corresponding entry of the L2P table.

9. The data storage device according to claim 8, wherein: In response to the second host command for the destination logical address, the controller is further configured to obtain the physical address from the corresponding entry of the L2P table.

10. The data storage device according to claim 8, in, The data storage device is configured to perform end-to-end data protection using at least logical address tags for user data; and The non-volatile memory stores therein a section of the user data marked with the source logical address.

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

12. A method performed by a data storage device receiving a command from a host device, the method comprising: in response to a first host command having a source logical address and a destination logical address, updating, with a controller, one or more entries in one or more tables stored in a control data memory to associate a physical address with the destination logical address, the physical address being associated with the source logical address in the one or more tables prior to the updating, the one or more tables comprising a logical-to-physical (L2P) table; as well as In response to a second host command having the destination logical address, at least one of the one or more entries is accessed with the controller to route the second host command to the physical address of the non-volatile memory.

13. The method according to claim 12, in, The first host command is a defragmentation command or a copy command; and The second host command is a read command.

14. The method according to claim 12, wherein: In response to the first host command and the second host command, no physical movement of user data is performed in the non-volatile memory.

15. The method according to claim 12, wherein: The updating includes invalidating the source logical address in the L2P table.

16. The method according to claim 1, in, The one or more tables include a fallback table; and The updating includes generating a table entry having the source logical address and the destination logical address in the backup table.

17. The method according to claim 16, wherein: The updating includes logically linking a table entry of the lookaside table and a corresponding entry of the L2P table.

18. The method according to claim 17, further comprising: In response to the second host command, the controller is used to obtain the physical address from a corresponding entry in the L2P table.

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

20. An apparatus for receiving a command from a host device, the apparatus comprising: means for updating, with a controller, one or more entries in one or more tables stored in a control data memory to associate a physical address with a destination logical address, the physical address being associated with a source logical address in the one or more tables prior to updating, the one or more tables comprising a logical-to-physical (L2P) table, the means for updating being executed in response to a first host command having the source logical address and the destination logical address; as well as Means for accessing, with the controller, at least one of the one or more entries to route a second host command having the destination logical address to the physical address of the non-volatile memory, the means for accessing being executed in response to the second host command.

Images