Patent Description:
Data stored in the system and the memory device becomes fragmented over time It slows down the performance of the system and the memory device by reducing the access and processing speed. Sometimes, it further causes undesirable corruption and data loss. Defragmentation is a process that reduces the degree of fragmentation by reorganizing a storage device's data for faster access and better system performance.

<CIT> describes a storage device including a nonvolatile memory and a controller configured to access the nonvolatile memory in response to a command from a host apparatus. <CIT> Al describes an example memory sub-system including a memory device and a processing device, operatively coupled to the memory device.

In one aspect, the memory controller includes a controller memory for storing a logical-to-physical (L2P) address mapping table corresponding to a file, and a controller processor configured to control a memory device, receive a mapping update command, and update the L2P address mapping table according to the mapping update command by replacing original logical addresses of logical block address (LBA) segments of the file with new continuous logical addresses of a merged LBA segment of the file, and changing an original mapping relation between the original logical addresses of the LBA segment of the file and physical addresses of the file, to a new mapping relation between the new continuous logical addresses of the merged LBA segment of the file and the physical addresses of the file.

In some implementations, the controller memory includes a volatile controller memory for storing the L2P address mapping table corresponding to the file.

In some implementations, the controller memory further includes a non-volatile controller memory. The controller processor is configured to store the updated L2P address mapping table in the non-volatile controller memory as a non-volatile L2P address mapping table.

In some implementations, the controller processor is configured to transmit an instruction to a host acknowledging that the L2P address mapping table has been updated.

In some implementations, the controller processor is configured to generate a merge log by recording the new mapping relation between the new continuous logical addresses of the merged LBA segment of the file and the physical addresses of the file.

In some implementations, in response to a sudden power loss, the controller processor is configured to rebuild the volatile L2P address mapping table according to a merge log recording the new mapping relation between the new continuous logical addresses of the merged LBA segment of the file the physical addresses of the file after a memory system being restarted.

In some implementations, the controller processor is configured to scan a physical-to-logical (P2L) address mapping table of a metadata block and the merge log, and in response to the merge log being updated, the controller processor is configured to rebuild the L2P address mapping table according to the merge log.

In another aspect, a memory system includes a memory device including a physical data block, and a memory controller including a controller memory for storing a logical-to-physical (L2P) address mapping table corresponding to a file, and a controller processor configured to control the memory device, receive a mapping update command, and update the L2P address mapping table according to the mapping update command by replacing original logical addresses of logical block address (LBA) segments of the file with new continuous logical addresses of a merged LBA segment of the file, and changing an original mapping relation between the original logical addresses of the LBA segment of the file and physical addresses of the file, to a new mapping relation between the new continuous logical addresses of the merged LBA segment of the file and the physical addresses of the file.

In some implementations, the controller memory further includes a non-volatile controller memory. The controller processor is configured to store the updated the L2P address mapping table in the non-volatile controller memory as a non-volatile L2P address mapping table.

In some implementations, in response to a sudden power loss, the controller processor is configured to rebuild the L2P address mapping table according to a merge log recording the new mapping relation between the new continuous logical addresses of the merged LBA segment of the file the physical addresses of the file after the memory system being restarted.

In still another aspect, a system includes a host including a host memory configured to store a file, and a host processor configured to execute a merge LBA command to rearrange original logical addresses of logical block address (LBA) segments of the file into new continuous logical addresses of a merged LBA segment of the file and send a mapping update command, and a memory system including a memory device comprising a physical data block, and a memory controller including a controller memory for storing a logical-to-physical (L2P) address mapping table corresponding to the file, and a controller processor configured to control the memory device, receive the mapping update command, and update the L2P address mapping table according to the mapping update command by replacing the original logical addresses of the LBA segments of the file with the new continuous logical addresses of the merged LBA segment of the file, and changing an original mapping relation between the original logical addresses of the LBA segment of the file and physical addresses of the file, to a new mapping relation between the new continuous logical addresses of the merged LBA segment of the file and the physical addresses of the file.

In some implementations, the host processor is configured to rearrange the original logical addresses of the LBA segments of the file into the new logical addresses of the merged LBA segment of the file by rewriting all logical addresses of the LBA segments of the file into a free or unused LBA segment with logical addresses in continuous and sequential order such that it becomes new continuous logical addresses of the merged LBA segment of the file.

In some implementations, the host processor is configured to send the mapping update command causing the memory controller to update the L2P address mapping table according to new continuous logical addresses of the merged LBA segment of the file.

In some implementations, the host processor is configured to receive an instruction from the memory controller acknowledging that the L2P address mapping table has been updated.

In some implementations, the host processor is configured to update an index node of the file after acknowledging that the L2P address mapping table has been updated.

In some implementations, the host processor is configured to update the index node of the file by pointing to a new LBA segment with the new continuous logical addresses of the merged LBA segment.

In yet still another aspect, a method for operating a memory controller includes receiving a mapping update command from a host, and updating a logical-to-physical (L2P) address mapping table according to the mapping update command by replacing the original logical addresses of the LBA segments of the file with the new continuous logical addresses of the merged LBA segment of the file, and changing an original mapping relation between the original logical addresses of the LBA segment of the file and physical addresses of the file, to a new mapping relation between the new continuous logical addresses of the merged LBA segment of the file and the physical addresses of the file.

In some implementations, the method further includes transmitting an instruction to the host acknowledging that the L2P address mapping table has been updated.

In some implementations, the method further includes recording, in a merge log, the new mapping relation between the new continuous logical addresses of the merged LBA segment of the file and the physical addresses of the file, and in response to a sudden power loss, rebuilding the L2P address mapping table according to the merge log after a memory system is restarted.

In some implementations, rebuilding the L2P address mapping table includes scanning a physical-to-logical (P2L) address mapping table of a metadata block and the merge log, and in response to determining that the merge log being updated, rebuilding the L2P address mapping table according to the merge log.

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate aspects of the present disclosure and, together with the description, further serve to explain the present disclosure and to enable a person skilled in the pertinent art to make and use the present disclosure.

Aspects of the present disclosure will be described with reference to the accompanying drawings.

Although specific configurations and arrangements are described, it should be understood that this is done for illustrative purposes only. As such, other configurations and arrangements can be used without departing from the scope of the present disclosure.

Disk defragmentation is a technique that allows users to defragment not only hard disk drive (HDD) but also other removable storage. For instance, Windows system, such as Windows <NUM>, includes a disk defragmentation utility called Microsoft Drive Optimizer or Disk Defragmenter that allows users to defrag their hard disk and increase the data access speed by rearranging files stored on the disk to occupy contiguous storage locations and improve computer's overall performance. Disk defragmentation, however, does not deem effective in solid-state drive (SSD). In fact, it is generally not recommended to defrag an SSD since it may use up write cycles of the SSD and potentially causes early death of the SSD. Nevertheless, with the development of the SSD and the increasing storage capacity in the SSD, the input/output stack (I/O stack) of software (SW) becomes a bottleneck of the system. That is, the fragmented file at the logical level reduces the performance of the system.

One of the solutions to solve fragmentation at the logical level is to use a defragmenter such as e2defrag. The e2defrag may read every segment of the logical address of a file and select a continuous logical address block to write. However, the e2defrag may not only update the logical address block but also update the physical block each time updating the logical address block, thereby increasing an effect of write amplification, which is an undesirable phenomenon associated with flash memory and solid-state drives where the actual amount of information physically written to the storage media is a multiple of the logical amount intended to be written. This write amplification may burn out the SSD fast than expected and shorten the lifespan of the SSD. Furthermore, conventional e2defrag is time-consuming due to its lengthy process of reading segments and routinely updating the physical address block each time updating the logical address block. It is not effective enough to solve the fragmentation problem at the logical level.

Moreover, conventional defragmentation tools may not have a very well design for power loss protection to ensure that the data is not lost while the SSD is writing data when a sudden power failure occurs. The sudden power loss may cause significant system corruption or data loss when the process of defragmentation is undergoing. A mechanism to prevent data loss from sudden power loss during defragmentation is highly desirable.

To address one or more of the aforementioned issues, the present disclosure introduces a solution in which a merged logical block address (LBA) command is designed to merge segments of LBA in a file into a merged LBA segment of the file and update a logical to physical (L2P) address mapping table according to the merged LBA segments of the file. Furthermore, a merge log is created to record a mapping relation between the L2P address mapping table and the physical-to-logical (P2L) address mapping table before updating the L2P address mapping table. Therefore, after a sudden power loss, the L2P can be rebuilt or restored by using the merge log and the P2L address mapping table.

<FIG> illustrates a block diagram of an exemplary system <NUM> having a memory device, according to some aspects of the present disclosure. System <NUM> can be a mobile phone, a desktop computer, a laptop computer, a tablet, a vehicle computer, a gaming console, a printer, a positioning device, a wearable electronic device, a smart sensor, a virtual reality (VR) device, an argument reality (AR) device, or any other suitable electronic devices having storage therein. As shown in <FIG>, system <NUM> can include a host <NUM> having a host memory <NUM> and a host processor <NUM>, and a memory system <NUM> having one or more memory devices <NUM> and a memory controller <NUM>.

Host <NUM> can be a processor of an electronic device, such as a central processing unit (CPU), or a system-on-chip (SoC), such as an application processor (AP). Host <NUM> can be coupled to memory controller <NUM> and configured to send or receive data to or from memory devices <NUM> through memory controller <NUM>. For example, host <NUM> may send the program data in a program operation or receive the read data in a read operation. Host processor <NUM> can be a control unit (CU), or an arithmetic & logic unit (ALU). Host memory <NUM> can be memory units including register or cache memory. Host <NUM> is configured to receive and transmit instructions and commands to and from memory controller <NUM> of memory device <NUM>, and execute or perform multiple functions and operations provided in the present disclosure, which will be described later.

Memory device <NUM> can be any memory device disclosed in the present disclosure, such as a NAND Flash memory device, which includes a page buffer having multiple portions, for example, four quarters. It is noted that the NAND Flash is only one example of the memory device for illustrative purposes. It can include any suitable solid-state, non-volatile memory, e.g., NOR Flash, Ferroelectric RAM (FeRAM), Phase-change memory (PCM), Magnetoresistive random-access memory (MRAM), Spin-transfer torque magnetic random-access memory (STT-RAM), or Resistive random-access memory (RRAM), etc. In some implementations, memory device <NUM> includes a three-dimensional (3D) NAND Flash memory device.

Memory controller <NUM> can be implemented by microprocessors, microcontrollers (a. microcontroller units (MCUs)), digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware, firmware, and/or software configured to perform the various functions described below in detail.

Memory controller <NUM> is coupled to memory device <NUM> and host <NUM> and is configured to control memory device <NUM>, according to some implementations. Memory controller <NUM> can manage the data stored in memory device <NUM> and communicate with host <NUM>. In some implementations, memory controller <NUM> is designed for operating in a low duty-cycle environment like secure digital (SD) cards, compact Flash (CF) cards, universal serial bus (USB) Flash drives, or other media for use in electronic devices, such as personal computers, digital cameras, mobile phones, etc. In some implementations, memory controller <NUM> is designed for operating in a high duty-cycle environment SSDs or embedded multi-media-cards (eMMCs) used as data storage for mobile devices, such as smartphones, tablets, laptop computers, etc., and enterprise storage arrays. Memory controller <NUM> can be configured to control operations of memory device <NUM>, such as read, erase, and program operations, by providing instructions, such as read instructions, to memory device <NUM>. For example, memory controller <NUM> may be configured to provide a read instruction to the peripheral circuit of memory device <NUM> to control the read operation. Memory controller <NUM> can also be configured to manage various functions with respect to the data stored or to be stored in memory device <NUM> including, but not limited to bad-block management, garbage collection, logical-to-physical address conversion, wear leveling, etc. In some implementations, memory controller <NUM> is further configured to process error correction codes (ECCs) with respect to the data read from or written to memory device <NUM>. Any other suitable functions may be performed by memory controller <NUM> as well, for example, formatting memory device <NUM>.

Memory controller <NUM> can communicate with an external device (e.g., host <NUM>) according to a particular communication protocol. For example, memory controller <NUM> may communicate with the external device through at least one of various interface protocols, such as a USB protocol, an MMC protocol, a peripheral component interconnection (PCI) protocol, a PCI-express (PCI-E) protocol, an advanced technology attachment (ATA) protocol, a serial-ATA protocol, a parallel-ATA protocol, a small computer small interface (SCSI) protocol, an enhanced small disk interface (ESDI) protocol, an integrated drive electronics (IDE) protocol, a Firewire protocol, etc..

Memory controller <NUM> and one or more memory devices <NUM> can be integrated into various types of storage devices, for example, being included in the same package, such as a universal Flash storage (UFS) package or an eMMC package. That is, memory system <NUM> can be implemented and packaged into different types of end electronic products. In one example as shown in <FIG>, memory controller <NUM> and a single memory device <NUM> may be integrated into a memory card <NUM>. Memory card <NUM> can include a PC card (PCMCIA, personal computer memory card international association), a CF card, a smart media (SM) card, a memory stick, a multimedia card (MMC, RS-MMC, MMCmicro), an SD card (SD, miniSD, microSD, SDHC), a UFS, etc. Memory card <NUM> can further include a memory card connector <NUM> coupling memory card <NUM> with a host (e.g., host <NUM> in <FIG>). In another example as shown in <FIG>, memory controller <NUM> and multiple memory devices <NUM> may be integrated into an SSD <NUM>. SSD <NUM> can further include an SSD connector <NUM> coupling SSD <NUM> with a host (e.g., host <NUM> in <FIG>). In some implementations, the storage capacity and/or the operation speed of SSD <NUM> is greater than those of memory card <NUM>.

Memory control <NUM> is configured to receive and transmit a command to and from host <NUM>, and execute or perform multiple functions and operations provided in the present disclosure, which will be described later.

<FIG> illustrates a schematic circuit diagram of an exemplary memory device <NUM> including peripheral circuits, according to some aspects of the present disclosure. Memory device <NUM> can be an example of memory device <NUM> in <FIG>. It is noted that the NAND Flash disclosed herein is only one example of the memory device for illustrative purposes. It can include any suitable solid-state, non-volatile memory, e.g., NOR Flash, FeRAM, PCM, MRAM, STT-RAM, or RRAM, etc. Memory device <NUM> can include a memory cell array <NUM> and peripheral circuits <NUM> coupled to memory cell array <NUM>. Memory cell array <NUM> can be a NAND Flash memory cell array in which memory cells <NUM> are provided in the form of an array of NAND memory strings <NUM> each extending vertically above a substrate (not shown). In some implementations, each NAND memory string <NUM> includes a plurality of memory cells <NUM> coupled in series and stacked vertically. Each memory cell <NUM> can hold a continuous, analog value, such as an electrical voltage or charge, which depends on the number of electrons trapped within a region of memory cell <NUM>. Each memory cell <NUM> can be either a floating gate type of memory cell including a floating-gate transistor or a charge trap type of memory cell including a charge-trap transistor.

In some implementations, each memory cell <NUM> is a single-level cell (SLC) that has two possible memory states and thus, can store one bit of data. For example, the first memory state "<NUM>" can correspond to a first range of voltages, and the second memory state "<NUM>" can correspond to a second range of voltages. In some implementations, each memory cell <NUM> is a multi-level cell (MLC) that is capable of storing more than a single bit of data in more than four memory states. For example, the MLC can store two bits per cell, three bits per cell (also known as triple-level cell (TLC)), or four bits per cell (also known as a quad-level cell (QLC)). Each MLC can be programmed to assume a range of possible nominal storage values. In one example, if each MLC stores two bits of data, then the MLC can be programmed to assume one of three possible programming levels from an erased state by writing one of three possible nominal storage values to the cell. A fourth nominal storage value can be used for the erased state.

As shown in <FIG>, each NAND memory string <NUM> can include a source select gate (SSG) transistor <NUM> at its source end and a drain select gate (DSG) transistor <NUM> at its drain end. SSG transistor <NUM> and DSG transistor <NUM> can be configured to activate selected NAND memory strings <NUM> (columns of the array) during read and program operations. In some implementations, the sources of NAND memory strings <NUM> in the same block <NUM> are coupled through a same source line (SL) <NUM>, e.g., a common SL. In other words, all NAND memory strings <NUM> in the same block <NUM> have an array common source (ACS), according to some implementations. The drain of DSG transistor <NUM> of each NAND memory string <NUM> is coupled to a respective bit line <NUM> from which data can be read or written via an output bus (not shown), according to some implementations. In some implementations, each NAND memory string <NUM> is configured to be selected or deselected by applying a select voltage (e.g., above the threshold voltage of DSG transistor <NUM>) or a deselect voltage (e.g., <NUM> V) to the gate of respective DSG transistor <NUM> through one or more DSG lines <NUM> and/or by applying a select voltage (e.g., above the threshold voltage of SSG transistor <NUM>) or a deselect voltage (e.g., <NUM> V) to the gate of respective SSG transistor <NUM> through one or more SSG lines <NUM>.

As shown in <FIG>, NAND memory strings <NUM> can be organized into multiple blocks <NUM>, each of which can have a common source line <NUM>, e.g., coupled to the ACS. In some implementations, each block <NUM> is the basic data unit for erase operations, i.e., all memory cells <NUM> on the same block <NUM> are erased at the same time. To erase memory cells <NUM> in a selected block <NUM>, source lines <NUM> coupled to selected block <NUM> as well as unselected blocks <NUM> in the same plane as selected block <NUM> can be biased with an erase voltage (Vers), such as a high positive voltage (e.g., <NUM> V or more). Memory cells <NUM> of adjacent NAND memory strings <NUM> can be coupled through word lines <NUM> that select which row of memory cells <NUM> is affected by the read and program operations. In some implementations, each word line <NUM> is coupled to a page <NUM> of memory cells <NUM>, which is the basic data unit for the program and read operations. The size of one page <NUM> in bits can relate to the number of NAND memory strings <NUM> coupled by word line <NUM> in one block <NUM>. Each word line <NUM> can include a plurality of control gates (gate electrodes) at each memory cell <NUM> in respective page <NUM> and a gate line coupling the control gates. Peripheral circuits <NUM> can be coupled to memory cell array <NUM> through bit lines <NUM>, word lines <NUM>, source lines <NUM>, SSG lines <NUM>, and DSG lines <NUM>. Peripheral circuits <NUM> can include any suitable analog, digital, and mixed-signal circuits for facilitating the operations of memory cell array <NUM> by applying and sensing voltage signals and/or current signals to and from each target memory cell <NUM> through bit lines <NUM>, word lines <NUM>, source lines <NUM>, SSG lines <NUM>, and DSG lines <NUM>. Peripheral circuits <NUM> can include various types of peripheral circuits formed using metal-oxide-semiconductor (MOS) technologies.

<FIG> illustrates a block diagram of an exemplary memory system <NUM> including a memory controller <NUM> and a memory device <NUM>, according to some aspects of the present disclosure. As shown in <FIG>, memory controller <NUM> can include a controller processor <NUM>, such as a memory chip controller (MCC) or a memory controller unit (MCU). Controller processor <NUM> is configured to control modules to execute commands or instructions to perform functions disclosed in the present disclosure. Controller processor <NUM> can also be configured to control the operations of each peripheral circuit by generating and sending various control signals, such as read commands for read operations. Controller processor <NUM> can also send clock signals at desired frequencies, periods, and duty cycles to other peripheral circuits <NUM> to orchestrate the operations of each peripheral circuit <NUM>, for example, for synchronization. Memory controller <NUM> can further include a volatile controller memory <NUM> and a non-volatile controller memory. Volatile controller memory <NUM> can include a register or cache memory such that it allows a faster access and process speed to read, write, or erase the data stored therein, while it may not retain stored information after power is removed. In some implementations, volatile controller memory <NUM> includes dynamic random-access memory (DRAM), Static random-access memory (SRAM). Non-volatile controller memory <NUM> can retain the stored information even after power is removed. In some implementations, non-volatile controller memory <NUM> includes NAND, NOR, FeRAM, PCM, MRAM, STT-RAM, or RRAM. Memory device <NUM> can include a memory cell array such as memory cell array <NUM> in <FIG>. In some implementations, non-volatile controller memory <NUM> can be not provided in the memory controller <NUM>, for example, non-volatile controller memory <NUM> is deposed outside of the memory controller <NUM> but is coupled to the memory controller <NUM>. In some implementations, the controller memory (e.g., <NUM> or <NUM>) is configured to store the L2P address mapping table (e.g., <NUM>, <NUM>) corresponding to the file (e.g., <NUM>).

<FIG> illustrates a block diagram of the exemplary memory system <NUM> including memory controller <NUM> and memory device <NUM>, according to some aspects of the present disclosure. As shown in <FIG>, memory controller <NUM> can include a memory controller interface <NUM> configured to receive and transmit commands or instructions to and from the host (e.g., host <NUM> in <FIG>). In some implementations, memory controller interface <NUM> is coupled to the controller processor <NUM> and to receive and transmit commands or instructions that cause controller processor <NUM> to perform functions disclosed in the present disclosure.

Memory controller <NUM> can also include an updating module <NUM> configured to generate and update a volatile L2P address mapping table <NUM>, a volatile merge log <NUM>, a non-volatile L2P mapping table <NUM>, and a non-volatile merge log <NUM>. Updating module <NUM> may be implemented through a firmware program in the firmware of controller processor <NUM>. In some implementations, updating module <NUM> is configured to update a physical data block <NUM> and/or a metadata block <NUM> in memory device <NUM>. In some implementations, updating module <NUM> is in controller processor <NUM> or coupled to controller processor <NUM>, and may be controlled by controller processor <NUM> to execute commands and instructions from host <NUM>. For instance, updating module <NUM> is configured to execute a mapping update command received from host <NUM> and update volatile L2P address mapping table <NUM> according to the mapping update command. In some implementations, updating module <NUM> is configured to update volatile L2P address mapping table <NUM> by rewriting a continuous logical address of a merged LBA segment of a file into volatile L2P address mapping table <NUM>. In some implementations, updating module <NUM> is configured to update volatile L2P address mapping table <NUM> by replacing original logical addresses of LBA segments of the file <NUM> with new continuous logical addresses of a merged LBA segment of the file, and changing an original mapping relation between the original logical addresses of the LBA segment of the file and physical addresses of the file, to a new mapping relation between the new continuous logical addresses of the merged LBA segment of the file and the physical addresses of the file. The process of forming the continuous logical address of the merged LBA segments of the file will be described later. And, after updating L2P address mapping table <NUM>, updating module <NUM> in controller processor <NUM> will transmit an instruction correspondingly to host <NUM> acknowledging that volatile L2P address mapping table <NUM> has been updated, so that host <NUM> may update the index node of the file in host memory <NUM>.

In some implementations, volatile L2P address mapping table <NUM> is stored and processed in volatile controller memory <NUM> and is configured to be transmitted and updated to non-volatile L2P address mapping table <NUM> stored in physical data block <NUM> so that the data will not be erased after power off. In some implementations, after the system being restarted, volatile L2P address mapping table <NUM> in volatile controller memory <NUM> can be loaded from non-volatile L2P address mapping table <NUM> in physical data block <NUM> for faster access and processing speed on a regular basis. In some implementations, non-volatile L2P address mapping table <NUM> can also be stored in non-volatile controller memory <NUM> of memory controller <NUM>.

Merge log (e.g., volatile merge log <NUM> and non-volatile merge log <NUM>) is configured to record a mapping relation between the L2P address mapping table (e.g., <NUM> or <NUM>) and the physical address of physical data block <NUM> before the updating of the L2P address mapping table. In some implementations, the merge log is configured to record a new mapping relation between the new continuous logical addresses of the merged LBA segment of file <NUM> and the physical addresses of file <NUM> each updating the L2P address mapping table. Therefore, after a sudden power loss, volatile L2P address mapping table <NUM>, which may not be updated yet, can be rebuilt or restored by using non-volatile merge log <NUM> and the physical address of physical data block <NUM> after the system (e.g., <NUM>) is restarted. It is noted that, in some implementations, the updating rate of non-volatile merge log <NUM> is faster than non-volatile L2P address mapping table <NUM> such that it is already recorded during a sudden power loss while it may not cause excessive write amplification since it is relatively small data comparing to non-volatile L2P address mapping table <NUM>. Specifically, in response to a sudden power loss, a recovery module <NUM> in controller processor <NUM> may scan a physical-to-logical (P2L) address mapping table <NUM> in metadata block <NUM> in memory device <NUM> and non-volatile merge log <NUM>, and in response to that non-volatile merge log <NUM> being updated, rebuild volatile L2P address mapping table <NUM> according to non-volatile merge log <NUM> and the physical address of physical data block <NUM> retained before the sudden power loss. And in response to that non-volatile merge log <NUM> is not updated, rebuild volatile L2P address mapping table <NUM> according to physical-to-logical (P2L) address mapping table <NUM> of metadata block <NUM> and the physical address of physical data block <NUM> retained before the sudden power loss. It is noted that metadata block <NUM> is a relatively small piece of a data block in memory cell array <NUM>. Metadata block <NUM> is configured to store logical address information of the data stored in physical data block <NUM>. The logical address information is written into metadata block <NUM> simultaneously when writing data into physical data block <NUM> so that it can recover data after the sudden power loss. In some implementations, volatile merge log <NUM> is stored and processed in volatile controller memory <NUM> and is configured to be transmitted and updated to non-volatile merge log <NUM> stored in physical data block <NUM> so that the data will not be erased after power off. In some implementations, after the system being restarted, volatile merge <NUM> in volatile controller memory <NUM> can be loaded from non-volatile merge log <NUM> in physical data block <NUM> for faster access and processing speed on a regular basis. In some implementations, non-volatile merge log <NUM> can also be stored in non-volatile controller memory <NUM> of memory controller <NUM>. Recovery module <NUM> may be implemented through a firmware program in the firmware of controller processor <NUM>.

<FIG> illustrates a block diagram of the exemplary system <NUM> including host <NUM> and memory controller <NUM>, according to some aspects of the present disclosure. As shown in <FIG>, host <NUM> may include a host interface <NUM>, host memory <NUM>, and host processor <NUM>. Host interface <NUM> is configured to receive commands or instructions from a user to perform or execute specific functions or operations. Host memory <NUM> may store logical addresses, e.g., a logical block address (LBA) of files (e.g., file <NUM>), and an index node <NUM> (e.g., inode) of the files. Host processor <NUM> may include or be coupled to an index node updating module <NUM> (e.g., inode updating module) and a merge LBA module <NUM>. Index node updating module <NUM> is configured to update index node <NUM> of the files after controller processor <NUM> (e.g., in <FIG>) of memory controller <NUM> transmits an instruction to host <NUM>, acknowledging that volatile L2P address mapping table <NUM> has been updated. Index node updating module <NUM> can also update index node <NUM> of the files after receiving an instruction that physical data block <NUM> (e.g., in <FIG>) has been updated. It is noted that the index node (e.g., inode) may be a data structure in a Unix-style file system that describes a file-system object such as a file or a directory. It can be a file data structure that stores information about any Linux file except its name and data. It stores metadata of the file including the file size, the device on which the file is stored, user and group IDs associated with the file, or permissions needed to access the file. In some implementations, host processor <NUM> is configured to update index node <NUM> of file <NUM> by pointing to a new LBA segment with the continuous logical addresses of the merged LBA segment.

Merge LBA module <NUM> that is included or coupled to host processor <NUM> is configured to execute a merge LBA command to rearrange the LBA segments (e.g., fragments of the logical address in a logical block) of file <NUM> into a merged LBA segment. For example, as in <FIG>, file A <NUM> may include one or more LBA segments (e.g., LBA segment <NUM>, LBA segment <NUM>, LBA segment <NUM>. , LBA segment N). When files are modified each time in the operation system, the number of the LBA segments increases, and the file becomes fragmented. When using the conventional e2defrag tool, as mentioned above, it may require reading multiple LBA segments one by one and finding a continuous logical address block to write a Segment New of the file. And then, the 2edefrag tool will update the physical data block according to the Segment New of the file. Therefore, each time the logical address block is updated, the physical data block is updated, thereby causing excessive write amplification. Merge LBA module <NUM>, as provided in the present disclosure, may therefore execute a merge LBA command to rearrange the LBA segments of file <NUM> into a merged LBA segment. Specifically, rearranging the LBA segment of file <NUM> includes rewriting all logical addresses of the LBA segments of file <NUM> into a free or unused logical address block (e.g., free or unused LBA segments) in continuous and sequential order such that it becomes a continuous logical address block (e.g., a merged LBA segment). Unlike the conventional e2defrag tool, the merged LBA segment will not be used to update the physical data block (e.g., physical data block <NUM> in <FIG>). The merged LBA segment is used to only update volatile L2P address mapping table <NUM> in <FIG>. By doing so, since there is no updating physical data block each time updating logical address block, the write amplification is minimized.

After executing the merge LBA command, host processor <NUM> may send a mapping update command causing controller processor (e.g., <NUM> in <FIG>) in memory controller <NUM> to update volatile L2P address mapping table <NUM> according to the merged LBA segment. As shown in <FIG>, volatile L2P address mapping table <NUM> with originally discontinuous and discrete logical addresses (e.g., LBA <NUM>, LBA <NUM>, LBA <NUM>, LBA <NUM>) which corresponds to the logical addresses of LBA segments (e.g., LBA <NUM>, LBA <NUM>, LBA <NUM>, LBA <NUM>) in file <NUM>, is updated to become a continuous logical address block (e.g., LBA <NUM>, LBA <NUM>, LBA <NUM>, LBA <NUM>). The physical addresses (e.g., PA <NUM>, PA <NUM>, PA <NUM>, PA <NUM>) of the updated volatile L2P address mapping table <NUM> directed to corresponding physical addresses of physical data block <NUM> remain unchanged in the above updating process. Therefore, after the defragmentation process, physical data block <NUM> has not been written and remains the same.

<FIG> illustrates a block diagram illustrating an exemplary defragmentation scheme under sudden power loss, according to some aspects of the present disclosure. As mentioned above, when a sudden power loss occurs, volatile L2P address mapping table <NUM> may not be updated or fail to complete the current updating, and therefore the data may be lost since the physical data is not updated as well. A metadata block (e.g., metadata block <NUM> in <FIG>) of a memory device (e.g., memory device <NUM>) may have an outdated and incorrect P2L mapping table (e.g., P2L address mapping table <NUM> in <FIG>) recording the physical addresses of outdated L2P address mapping table (e.g., LBA <NUM>, LBA <NUM>, LBA <NUM>, LBA <NUM>). Because non-volatile merge log <NUM> stores a mapping relation between P2L address mapping table <NUM> and volatile L2P address mapping table <NUM> (e.g., LBA <NUM> of P2L points to LBA <NUM> of new L2P, LBA <NUM> of P2L points to LBA <NUM> of new L2P, LBA <NUM> of P2L points to LBA <NUM> if new L2P, LBA <NUM> of P2L points to LBA <NUM> of new L2P) after each updating volatile L2P address mapping table <NUM>, a new volatile L2P address mapping table <NUM> can be rebuilt by using non-volatile merge log <NUM> and the retained P2L address mapping table <NUM> according to the mapping relation.

<FIG> illustrates a flowchart of an exemplary method for operating a memory controller, according to some aspects of the present disclosure. The memory controller may be any suitable memory controller disclosed herein, e.g., memory controller <NUM> in <FIG>. Method <NUM> may be implemented partially or fully by memory controller <NUM> as in <FIG>. It is understood that the operations shown in method <NUM> may not be exhaustive and that other operations can be performed as well before, after, or between any of the illustrated operations. Further, some of the operations may be performed simultaneously, or in a different order than shown in <FIG>.

Referring to <FIG>, method <NUM> starts at operation <NUM> in which a memory controller (e.g., memory controller <NUM> as in <FIG>) receives a mapping update command from a host (e.g., host <NUM> in <FIG>). In some implementations, the mapping update command may cause memory controller <NUM> to start updating module <NUM>.

Method <NUM> proceeds to operation <NUM>, as illustrated in <FIG>, in which an L2P address mapping table (e.g., volatile L2P address mapping table <NUM> in <FIG>) stored in memory controller <NUM> is updated according to the mapping update command. In some implementations, updating the L2P address mapping table includes rewriting a continuous logical address of a merged LBA segment of a file (e.g., file <NUM> in <FIG>) into the L2P address mapping table.

Method <NUM> proceeds to operation <NUM>, as illustrated in <FIG>, in which an instruction is transmitted to the host acknowledging that the L2P address mapping table has been updated after updating the L2P address mapping table. In some implementations, once the updating L2P address mapping table is completed, the updating module is configured to transmit an instruction through an interface (e.g., memory controller interface <NUM> in <FIG>) to the host. The host may then update the index node of the file stored in the host memory.

Furthermore, method <NUM> may further include an operation in which a sudden power loss protection is implemented. Specifically, method <NUM> may also include recording, in a merge log (e.g., non-volatile merge log <NUM> in <FIG>), a mapping relation between a P2L address mapping table (e.g., P2L mapping table in <FIG>) in a metadata block (e.g., metadata block <NUM> in <FIG>) and the L2P address mapping table. After a sudden power loss and when the system is restarted, method <NUM> may further include scanning the P2L address mapping table of the metadata block and the merge log. And in response to determining that the merge log is updated, the L2P address mapping table is rebuilt according to the merge log and the P2L address mapping table of the metadata block. And also, in response to determining that the merge log is not updated, the L2P address mapping table is restored according to the P2L address mapping table of the metadata block. These operations can be implemented by recovery module <NUM> as in <FIG>.

<FIG> illustrates a flowchart of an exemplary method for operating a host, according to some aspects of the present disclosure. The host may be any suitable host disclosed herein. Method <NUM> may be implemented partially or fully by host <NUM> as in <FIG>. It is understood that the operations shown in method <NUM> may not be exhaustive and that other operations can be performed as well before, after, or between any of the illustrated operations. Further, some of the operations may be performed simultaneously, or in a different order than shown in <FIG>.

Referring to <FIG>, method <NUM> starts at operation <NUM> in which a merge LBA command is executed to rearrange LBA segments of a file (e.g., file <NUM> as in <FIG>) stored in a host memory (e.g., host memory <NUM> in <FIG>) into a merged LBA segment. In some implementations, the merge LBA command may cause a host processor (e.g., host processor <NUM> in <FIG>) to start a merge LBA module (e.g., merge LBA module <NUM> in <FIG>). In some implementations, rearranging the LBA segments of the file into the merged LBA segment includes rewriting the LBA segments of the file with logical addresses in discontinuous or discrete order, into the merged LBA segment with logical addresses in continuous and sequential order. In some implementations, rearranging the LBA segments of the file into the merged LBA segment includes sequentially reading the logical addresses of the LBA segments of the file before rewriting the logical addresses of the merged LBA segment, such that it becomes the merged LBA segment that has each and every LBA segments of the file.

Method <NUM> proceeds to operation <NUM>, as illustrated in <FIG>, in which a mapping update command is transmitted to a memory controller (e.g., memory controller <NUM> in <FIG>), causing a controller processor (e.g., controller processor <NUM> in <FIG>) of the memory controller to update an L2P address mapping table (e.g., volatile L2P address mapping table <NUM> in <FIG>) according to the merged LBA segment. In some implementations, updating the L2P address mapping table includes rewriting continuous logical addresses of the merged LBA segment of the file into the L2P address mapping table.

Method <NUM> proceeds to operation <NUM>, as illustrated in <FIG>, in which an instruction is received from the controller processor acknowledging that the L2P address mapping table has been updated. In some implementations, after receiving the instruction, an index node update module (e.g., index node updating module <NUM>) is started.

Claim 1:
A memory controller (<NUM>), comprising:
a controller memory (<NUM>, <NUM>) configured to store a logical-to-physical, L2P, address mapping table (<NUM>, <NUM>) corresponding to a file (<NUM>); and
a controller processor (<NUM>) configured to control a memory device (<NUM>), receive a mapping update command, and update the L2P address mapping table (<NUM>, <NUM>) according to the mapping update command by:
replacing original logical addresses of logical block address, LBA, segments of the file (<NUM>) with new continuous logical addresses of a merged LBA segment of the file (<NUM>), and
changing an original mapping relation between the original logical addresses of the LBA segment of the file (<NUM>) and physical addresses of the file (<NUM>), to a new mapping relation between the new continuous logical addresses of the merged LBA segment of the file (<NUM>) and the physical addresses of the file (<NUM>);
the controller processor (<NUM>) is further configured to transmit the updated L2P address mapping table (<NUM>, <NUM>) to a physical data block of the memory device (<NUM>) and transmit an instruction to the host (<NUM>) acknowledging that the L2P address mapping table (<NUM>, <NUM>) has been updated, wherein the controller processor (<NUM>) is configured to generate a merge log (<NUM>) by recording the new mapping relation between the new continuous logical addresses of the merged LBA segment of the file (<NUM>) and the physical addresses of the file (<NUM>) and transmit the merge log (<NUM>) to the physical data block of the memory device (<NUM>).