Journal update prior to logical-to-physical memory address update

Abstract

Various example embodiments provide for performing a journal update prior to logical-to-physical (L2P) memory address information update on a memory system. According to various example embodiments, a journal update to a journal buffer prior to L2P memory address information being updated in an L2P table of a memory system. Additionally, for some example embodiments, data content of the journal buffer is not written to a non-volatile memory device (as a journal buffer data dump) until all related handler requests for a logical block handler are completed by the logical block handler and the logical block handler has indicated as such.

Description

JOURNAL UPDATE PRIOR TO LOGICAL-TO-PHYSICAL MEMORY ADDRESS UPDATETECHNICAL FIELD

[0001] Embodiments of the disclosure relate generally to memory devices and, more specifically, to performing a journal update prior to logical-to-physical memory address information update on a memory system, such as a memory sub-system.BACKGROUND

[0002] A memory sub-system can include one or more memory devices that store data. The memory devices can be, for example, non-volatile memory devices and volatile memory devices. In general, a host system can utilize a memory sub-system to store data at the memory devices and to retrieve data from the memory devices.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The disclosure will be understood more fully from the detailed description given below and from the accompanying drawings of various example embodiments of the disclosure. The drawings, however, should not be taken to limit the disclosure to the specific example embodiments, but are for explanation and understanding only.

[0004] FIG. 1 is a block diagram illustrating an example computing system that includes a memory sub-system, in accordance with some example embodiments of the present disclosure.

[0005] FIG. 2 and FIG. 3 are flow diagrams of example methods for performing a journal update prior to logical-to-physical memory address information update on a memory system, in accordance with some example embodiments of the present disclosure.

[0006] FIG. 4 is a block diagram illustrating an example of sections of an L2P table of a memory system and a journal buffer data dump being stored on a non-volatile memory device of the memory system, in accordance with some example embodiments of the present disclosure.

[0007] FIG. 5 is a diagram illustrating example operations for performing a journal update prior to logical-to-physical memory address information update within an example memory system, in accordance with some example embodiments of the present disclosure.

[0008] FIG. 6 illustrates a diagram of an example timeline of operations being performed within a memory system, in accordance with some example embodiments of the present disclosure.

[0009] FIG. 7 is a block diagram of an example computer system in which example embodiments of the present disclosure may operate.DETAILED DESCRIPTION

[0010] Aspects of the present disclosure are directed to performing a journal update prior to logical-to-physical memory address information update on a memory system, such as a memory sub-system. A memory sub-system can be a storage device, a memory module, or a hybrid of a storage device and memory module. Examples of storage devices and memory modules are described below in conjunction with FIG. 1. In general, a host system can utilize a memory sub-system that includes one or more components, such as memory devices that store data. The host system can send access requests to the memory sub-system, such as to store data at the memory sub-system and to read data from the memory sub-system.

[0011] The host system can send access requests (e.g., write command, read command) to the memory sub-system, such as to store data on a memory device at the memory sub-system, read data from the memory device on the memory sub-system, or write / read constructs (e.g., such as submission and completion queues) with respect to a memory device on the memory sub-system. The data to be read or written, as specified by a host request, is hereinafter referred to as “host data” or “user data. ”

[0012] A host request can include logical address information (e.g., logical block address (LBA) , namespace) for the host data, which is the location the host system associates with the host data and a particular zone in which to store or access the host data. The logical address information (e.g., LBA, namespace) can be part of metadata for the host data. Metadata can also include error handling data (e.g., error-correcting code (ECC) code word, parity code) , data version (e.g., used to distinguish age of data written) , valid bitmap (which LBAs or logical transfer units contain valid data) , and so forth.

[0013] As used herein, a logical memory address can comprise a logical block address (LBA) , which can be provided by a host system to a memory device or a memory sub-system. For example, depending on a physical interface used between a host system and a memory device / memory sub-system, an LBA can comprise a 2-byte or 4-byte number. As used herein, a  physical memory address can comprise a memory address on a memory device or a memory sub-system where data (e.g., user data) is stored. For example, the physical memory address can comprise a physical block address (PBA) , which can be a position within an underling non-volatile memory device that can be identified by a 4-byte number or a tuple of numbers (e.g., die ID, block ID, page ID) . As used herein, an address mapping data can comprise logical memory address-to-physical memory address (L2P) data (e.g., L2P mapping or translation table) , which can associate (and therefore facilitate translation or reconstruction of) a logical memory address to a physical memory address of a memory device or a memory sub-system.

[0014] The memory sub-system can initiate media management operations, such as a write operation, on host data that is stored on a memory device. For example, firmware of the memory sub-system may re-write previously written host data from a location of a memory device to a new location as part of garbage collection management operations. The data that is re-written, for example as initiated by the firmware, is hereinafter referred to as “garbage collection data. ”

[0015] “User data” hereinafter generally refers to host data and garbage collection data. “System data” hereinafter refers to data that is created and / or maintained by the memory sub-system for performing operations in response to host requests and for media management. Examples of system data include, and are not limited to, system tables (e.g., logical-to-physical memory address mapping table (also referred to herein as an L2P table) , data from logging, scratch pad data, and so forth) .

[0016] A memory device can be a non-volatile memory device. A non-volatile memory device is a package of one or more die. Each die can be comprised of one or more planes. For some types of non-volatile memory devices (e.g., AND-type devices) , each plane is comprised of a set of physical blocks. For some memory devices, blocks are the smallest area that can be erased. Each block is comprised of a set of pages. Each page is comprised of a set of memory cells, which store bits of data. The memory devices can be raw memory devices (e.g., NAND) , which are managed externally, for example, by an external controller. The memory devices can be managed memory devices (e.g., managed NAND) , which are a raw memory device combined with a local embedded controller for memory management within the same memory device package. The memory device can be divided into one or more zones where each zone is associated with a different set of host data or user data or application.

[0017] Certain memory devices, such as NAND-type memory devices, comprise one or more blocks, (e.g., multiple blocks) , with each of those blocks comprising multiple memory cells. For  instance, a memory device can comprise multiple pages (also referred to as wordlines) , with each page comprising a subset of memory cells of the memory device. A threshold voltage (VT) of a memory cell (of a block) can be the voltage at which the floating gate (e.g., NAND transistor) , implementing the memory cell, turns on and conducts (e.g., to a bit line coupled to the memory cell) . Generally, writing data to such memory devices involves programming (by way of a program operation) the memory devices at the page level of a block, and erasing data from such memory devices involves erasing the memory devices at the block level (e.g., page level erasure of data is not possible) .

[0018] Certain memory sub-systems, such as solid-state drives (SSDs) , rely on logical-to-physical (L2P) address translation to map LBAs used by the host system to physical locations (e.g., PBAs) in one or more memory devices (e.g., NAND-type memory device) of the memory sub-system. As memory sub-system capacities and performance requirements have grown, managing this L2P mapping efficiently has become more challenging. For example, a memory sub-system typically stores the full L2P table on local, volatile memory of the memory sub-system (e.g., dynamic random access memory (DRAM) ) during the memory sub-system's operation (for fast access to the L2P information contained therein and to enable updates to the L2P table as instantly as user data) , but also stores the L2P table on non-volatile memory (e.g., persistent memory, such a NAND-type memory device) of the memory sub-system, which is slower than the local volatile memory. The L2P table is stored on the non-volatile memory for when the memory sub-system is offline (e.g., the memory sub-system is powered down, is restarted, or unexpectedly loses power) and the L2P table needs to be reloaded to local volatile memory for use once memory sub-system is online (e.g., operational) again. However, the typically large size of L2P tables (e.g., 32 GB for a 32 TB SSD) can render it impractical to update the entire L2P table in both the local volatile memory and the non-volatile memory (e.g., persistent memory) simultaneously.

[0019] To address this, memory sub-systems (such as SSDs) can divide the L2P table into portions or sections that are periodically stored (e.g., dumped) to the non-volatile memory (e.g., NAND-type memory device) as portion / section snapshots. This approach allows the entire L2P table to be written (e.g., programmed) into the persistent storage media periodically (e.g., circularly) and allows for more frequent updates to the L2P table in the local volatile memory (e.g., in near real-time) , while minimizing the impact on input / output (I / O) performance by deferring the commitment of those updates to non-volatile memory for a later time (based on the  periodic storage of L2P table sections) . The approach can also create the potential for data loss in the event of unexpected power loss to the memory sub-system, as the most recent L2P updates stored on the local volatile memory may not yet be stored (e.g., persisted) to the non-volatile memory (e.g., NAND-type memory device) of the memory sub-system.

[0020] To mitigate this risk, memory sub-systems can employ journaling techniques, where a journal buffer in the local volatile memory can record journal entries for recent L2P updates before the recent L2P updates naturally propagate from corresponding sections of the L2P table on the non-volatile memory via a periodic data dump. As used herein, a journal can refer to a mechanism (implemented using software, hardware, or both) used to record changes to data (recorded as individual journal entries) before changes are committed to data on non-volatile memory (e.g., before the changed data is persisted to the non-volatile memory) . When the journal buffer (comprising defined data space on the volatile memory) is full, the journal buffer can also be stored (e.g., persisted to) on the non-volatile memory and then the journal buffer on the local volatile memory can be emptied, thereby flushing the journal buffer to the non-volatile memory as a journal buffer data dump. In this way, the journal entries (of recent changes) stored in the journal buffer stored on the non-volatile memory and later used to reconstruct the latest L2P state on the local volatile memory during recovery of the L2P table from the non-volatile memory (e.g., after a power loss of the memory sub-system, the snapshots are reloaded to volatile memory and those reloaded snapshots are patched based on journal entries containing newer L2P information) . An example of storing snapshots and the journaling buffer data on the non-volatile memory device is illustrated and described with respect to FIG. 4. Overall, the conventional snapshot and journaling approach can result in a snapshot of each L2P section being stored in the persistent storage media (e.g., as flash translation layer (FTL) blocks) , and the latest written data not updated in the snapshot yet can be tracked by journal entries (in the journal buffer) that comprise the updated logical and physical memory address information (e.g., as user data changes) .

[0021] In order to support the processing of large quantities of outstanding L2P updates, the conventional journaling approach described above involves adding journal entries to a journal buffer implemented on a slower volatile memory device (rather than a faster volatile memory device, such as static random access memory (SRAM) of the memory sub-system, to conserve data space on the faster volatile memory device (for other, high priority tasks on the memory sub-system) . Additionally, at present, a journal entry is not added until a corresponding L2P  update finishes, which can guarantee that the L2P update is really written to the L2P table on a volatile memory device (e.g., DRAM) when a journal buffer is flushed to a non-volatile memory device. Unfortunately, the journal entries are added to the journal buffer by reading entry update information from the slower volatile memory device, which can be too inefficient for modern and future memory device specifications (e.g., a PCIe Generation 5 / 6 memory device) . For example, as SSD interface speeds have increased (e.g., PCIe Generation 5 / 6) , the demands on the L2P update and the conventional journaling approach have grown significantly. For instance, an SSD are now expected to support much higher I / O rates, putting pressure on the efficiency of processes such as L2P update. Additionally, the conventional snapshot and journaling approach can result in a race condition, where one or more L2P section snapshots stored on non-volatile memory may not be newer than journal entries of the journal buffer data dump stored on non-volatile memory, and certain journal entries will be skipped during the reconstruction process by mistake, resulting in data loss.

[0022] Various example embodiments described herein provide for performing a journal update prior to logical-to-physical memory address information update on a memory system. In particular, various example embodiments reduce the processing overhead on a memory system of reading logical memory address and physical memory address information from slow (or slower) volatile memory during a journal update and avoid possible race conditions. According to various example embodiments, a journal update (e.g., journal entries) to a journal buffer prior to L2P memory address information being updated in an L2P table of a memory system. Additionally, for some example embodiments, data content of the journal buffer is not written (e.g., programmed) to a non-volatile memory device (as a journal buffer data dump) until all L2P memory address update entries in a related / associated handler request (e.g., related / associated with the journal buffer data dump) are completed by a logical block handler (e.g., LBA handler) and the logical block handler has indicated (e.g., provided a response indicating) as such.

[0023] Disclosed herein are some examples of performing a journal update prior to logical-to-physical memory address information update on a memory system, as described herein.

[0024] FIG. 1 illustrates an example computing system 100 that includes a memory sub-system 110, in accordance with some example embodiments of the present disclosure. The memory sub-system 110 can include media, such as one or more volatile memory devices (e.g., memory device 140) , one or more non-volatile memory devices (e.g., memory device 130) , or a combination of such.

[0025] A memory sub-system 110 can be a storage device, a memory module, or a hybrid of a storage device and memory module. Examples of a storage device include a solid-state drive (SSD) , a flash drive, a universal serial bus (USB) flash drive, a secure digital (SD) card, an embedded Multi-Media Controller (eMMC) drive, a Universal Flash Storage (UFS) drive, and a hard disk drive (HDD) . Examples of memory modules include a dual in-line memory module (DIMM) , a small outline DIMM (SO-DIMM) , and various types of non-volatile dual in-line memory module (NVDIMM) .

[0026] The computing system 100 can be a computing device such as a desktop computer, laptop computer, network server, mobile device, a vehicle (e.g., airplane, drone, train, automobile, or other conveyance) , Internet of Things (IoT) enabled device, embedded computer (e.g., one included in a vehicle, industrial equipment, or a networked commercial device) , or such computing device that includes memory and a processing device. The computing system 100 can be used to support or implement various types of applications, including those relating to artificial intelligence (AI) .

[0027] The computing system 100 can include a host system 120 that is coupled to one or more memory sub-systems 110. In some example embodiments, the host system 120 is coupled to different types of memory sub-systems 110. FIG. 1 illustrates one example of a host system 120 coupled to one memory sub-system 110. As used herein, “coupled to” or “coupled with” generally refers to a connection between components, which can be an indirect communicative connection or direct communicative connection (e.g., without intervening components) , whether wired or wireless, including connections such as electrical, optical, magnetic, and the like.

[0028] The host system 120 can include a processor chipset and a software stack executed by the processor chipset. The processor chipset can include one or more cores, one or more caches, a memory controller (e.g., NVDIMM controller) , and a storage protocol controller (e.g., a peripheral component interconnect express (PCIe) controller, serial advanced technology attachment (SATA) controller) . The host system 120 uses the memory sub-system 110, for example, to write data to the memory sub-system 110 and read data from the memory sub-system 110.

[0029] The host system 120 can include or be coupled to the memory sub-system 110 so that the host system 120 can read data from or write data to the memory sub-system 110. The host system 120 can be coupled to the memory sub-system 110 via a physical host interface. Examples of a physical host interface include, but are not limited to, a serial advanced technology  attachment (SATA) interface, a peripheral component interconnect express (PCIe) interface, a compute express link (CXL) interface, a universal serial bus (USB) interface, a Fibre Channel interface, a Serial Attached SCSI (SAS) interface, etc. The physical host interface can be used to transmit data between the host system 120 and the memory sub-system 110. The host system 120 can further utilize an NVM Express (NVMe) interface to access the memory devices 130, 140 when the memory sub-system 110 is coupled with the host system 120 by the PCIe or CXL interface. The physical host interface can provide an interface for passing control, address, data, and other signals between the memory sub-system 110 and the host system 120.

[0030] The memory devices 130, 140 can include any combination of the different types of non-volatile memory devices and / or volatile memory devices. The volatile memory devices (e.g., memory device 140) can be, but are not limited to, random access memory (RAM) , such as dynamic random access memory (DRAM) and synchronous dynamic random access memory (SDRAM) .

[0031] Some examples of non-volatile memory devices (e.g., memory device 130) include a NAND type flash memory and write-in-place memory, such as a three-dimensional (3D) cross-point memory device, which is a cross-point array of non-volatile memory cells. A cross-point array of non-volatile memory can perform bit storage based on a change of bulk resistance, in conjunction with a stackable cross-gridded data access array. Additionally, in contrast to many flash-based memories, cross-point non-volatile memory can perform a write in-place operation, where a non-volatile memory cell can be programmed without the non-volatile memory cell being previously erased. NAND type flash memory includes, for example, two-dimensional (2D) NAND and 3D NAND.

[0032] Each of the memory devices 130, 140 can include one or more arrays of memory cells. One type of memory cell, for example, SLCs, can store one bit per cell. Other types of memory cells, such as MLCs, TLCs, QLCs, and penta-level cells (PLCs) , can store multiple bits per cell. In some example embodiments, each of the memory devices 130, 140 can include one or more arrays of memory cells such as SLCs, MLCs, TLCs, QLCs, or any combination of such. In some example embodiments, a particular memory device can include an SLC portion, and an MLC portion, a TLC portion, or a QLC portion of memory cells. The memory cells of the memory devices 130, 140 can be grouped as pages that can refer to a logical unit of the memory device used to store data. With some types of memory (e.g., NAND) , pages can be grouped to form blocks. As used herein, a block comprising SLCs can be referred to as a SLC block, a block  comprising MLCs can be referred to as an MLC block, a block comprising TLCs can be referred to as a TLC block, and a block comprising QLCs can be referred to as a QLC block.

[0033] Although non-volatile memory components such as NAND type flash memory (e.g., 2D NAND, 3D NAND) and 3D cross-point array of non-volatile memory cells are described, the memory device 130 can be based on any other type of non-volatile memory, such as read-only memory (ROM) , phase change memory (PCM) , self-selecting memory, other chalcogenide-based memories, ferroelectric transistor random-access memory (FeTRAM) , ferroelectric random access memory (FeRAM) , magneto random access memory (MRAM) , Spin Transfer Torque (STT) -MRAM, conductive bridging RAM (CBRAM) , resistive random access memory (RRAM) , oxide-based RRAM (OxRAM) , negative-or (NOR) flash memory, and electrically erasable programmable read-only memory (EEPROM) .

[0034] A memory sub-system controller 115 (or controller 115 for simplicity) can communicate with the memory devices 130, 140 to perform operations such as reading data, writing data, or erasing data at the memory devices 130, 140 and other such operations. The memory sub-system controller 115 can include hardware such as one or more integrated circuits and / or discrete components, a buffer memory, or a combination thereof. The hardware can include digital circuitry with dedicated (i.e., hard-coded) logic to perform the operations described herein. The memory sub-system controller 115 can be a microcontroller, special purpose logic circuitry (e.g., a field programmable gate array (FPGA) , an application specific integrated circuit (ASIC) , etc. ) , or other suitable processor.

[0035] The memory sub-system controller 115 can include a processor (processing device) 117 configured to execute instructions stored in local memory 119. In the illustrated example, the local memory 119 of the memory sub-system controller 115 includes an embedded memory configured to store instructions for performing various processes, operations, logic flows, and routines that control operation of the memory sub-system 110, including handling communications between the memory sub-system 110 and the host system 120.

[0036] In some example embodiments, the local memory 119 can include memory registers storing memory pointers, fetched data, and so forth. The local memory 119 can also include ROM for storing micro-code. While the example memory sub-system 110 in FIG. 1 has been illustrated as including the memory sub-system controller 115, in another example embodiment of the present disclosure, a memory sub-system 110 does not include a memory sub-system controller  115, and can instead rely upon external control (e.g., provided by an external host, or by a processor or controller separate from the memory sub-system) .

[0037] In general, the memory sub-system controller 115 can receive commands or operations from the host system 120 and can convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory device 130 and / or the memory device 140. The memory sub-system controller 115 can be responsible for other operations such as wear leveling operations, garbage collection operations, error detection and ECC operations, encryption operations, caching operations, and address translations between a logical address (e.g., LBA, namespace) and a physical memory address (e.g., physical block address) that are associated with the memory devices 130, 140. The memory sub-system controller 115 can further include host interface circuitry to communicate with the host system 120 via the physical host interface. The host interface circuitry can convert the commands received from the host system 120 into command instructions to access the memory device 130 and / or the memory device 140 as well as convert responses associated with the memory device 130 and / or the memory device 140 into information for the host system 120.

[0038] The memory sub-system 110 can also include additional circuitry or components that are not illustrated. In some example embodiments, the memory sub-system 110 can include a cache or buffer (e.g., DRAM) and address circuitry (e.g., a row decoder and a column decoder) that can receive an address from the memory sub-system controller 115 and decode the address to access the memory devices 130, 140.

[0039] In some example embodiments, the memory device 130 includes local media controller 135 that operates in conjunction with memory sub-system controller 115 to execute operations on one or more memory cells of the memory device 130. An external controller (e.g., memory sub-system controller 115) can externally manage the memory device 130 (e.g., perform media management operations on the memory device 130) . In some example embodiments, a memory device 130 is a managed memory device, which is a raw memory device combined with a local controller (e.g., local media controller 135) for media management within the same memory device package. An example of a managed memory device is a managed NAND (MNAND) device.

[0040] The memory sub-system controller 115 includes a journal entry generator 113 (hereafter, the journal entry generator 113) that enables or facilitates pre-L2P table update journal entry generation on the memory sub-system 110 in accordance with various example embodiments  described herein. Alternatively, some or all of the journal entry generator 113 is included by the local media controller 135, thereby enabling the local media controller 135 to enable or facilitate pre-L2P table update journal entry generation on the memory sub-system 110.

[0041] FIG. 2 and FIG. 3 are flow diagrams of example methods 200, 300 for performing a journal update prior to logical-to-physical memory address information update on a memory system, in accordance with some example embodiments of the present disclosure. Any of method 200 or 300 can be performed by processing logic that can include hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc. ) , software (e.g., instructions run or executed on a processing device) , or a combination thereof. In some example embodiments, method 200 or 300 is performed by the memory sub-system controller 115 of FIG. 1 based on the journal entry generator 113. Additionally, or alternatively, for some example embodiments, the method 200 or 300 is performed, at least in part, by the local media controller 135 of the memory device 130 of FIG. 1.Although shown in a particular sequence or order, unless otherwise specified, the order of the processes can be modified. Thus, the illustrated example embodiments should be understood only as examples, and the illustrated processes can be performed in a different order, and some processes can be performed in parallel. Additionally, one or more processes can be omitted in various example embodiments. Thus, not all processes are used in every example embodiment. Other process flows are possible.

[0042] Referring now to method 200 of FIG. 2, at operation 204 a processing device (e.g., the processor 117 of the memory sub-system controller 115) receives an L2P memory address update request. For example, the L2P memory address update request can be generated and received (e.g., by the processing device) as data (e.g., user data) on the memory system is updated (e.g., written or moved based on host commands) .

[0043] During operation 206, the processing device (e.g., 117) adds an L2P memory address update entry, for the L2P memory address update request (received at operation 204) , to a handler request (e.g., an L2P update request message) for a logical block handler. For instance, the L2P memory address update entry comprises an individual logical memory address of the memory system, and an individual physical memory address of the memory system to which the individual logical memory address maps. The handler request can be stored on a volatile memory device, which can function as coherent memory within the memory system. For various example embodiments, the logical block handler is configured to update an L2P table on the volatile  memory device of the memory system (e.g., memory sub-system 110) based on the handler request. Depending on the example embodiment, the logical block handler can be implemented by software (e.g., firmware) , hardware, or a combination of both. For instance, the logical block handler can comprise a hardware module that can atomically handle L2P updates (e.g., LBA update) to support bandwidth to match high host speed. For some example embodiments, the logical block handler comprises an LBA handler. Additionally, for some example embodiments, the L2P table comprises information that maps logical memory addresses to physical memory addresses on the memory system (e.g., memory sub-system 110) . For example, the logical memory addresses can comprise LBAs (e.g., 64-bit LBAs) , and the physical memory addresses can comprise PBAs (e.g., 64-bit PBAs) . According to some embodiments, the volatile memory device comprises a first data space on the volatile memory device that implements a journal buffer, and a second data space that stores the L2P table.

[0044] At operation 208, the processing device (e.g., 117) adds an L2P journal entry, for the L2P memory address update request, to a journal buffer on a volatile memory device (e.g., local memory 119) of a memory system (e.g., memory sub-system 110) . For some embodiments, the volatile memory device represents a slow (or slower) volatile memory device (where the journal buffer and handler requests are stored on the slow / slower volatile memory device) , and a single variable stored on a different, fast (or faster) volatile memory device of the memory system is used to add the L2P memory address update entry (at operation 206) and to add the L2P journal entry to the journal buffer (at operation 208) , thereby ensuring both operations are performed quickly (e.g., can facilitate direct update of a new journal entry together with an L2P update request submission in a single application program interface (API) context) . The single variable can comprise a global variable or a stack variable with a logical and a physical address in the fast (or faster) memory device. Depending on the example embodiment, the slow / slower volatile memory device can be one that is slower than the fast / faster volatile memory device (e.g., the slow / slower volatile memory device and fast / faster volatile memory device are different memory device types) , one that is slower for the processing device to access than the fast / faster volatile memory device because of data path differences (e.g., slow / slower volatile memory device is on a different or more distant data bus) , or both. Additionally, depending on the example embodiment, the slow / slower volatile memory device can comprise a DRAM device or a SRAM device, and the fast / faster volatile memory device can comprise a DRAM device or a SRAM device.

[0045] Thereafter, at operation 210, the processing device (e.g., 117) sends (e.g., issues) the handler request (e.g., L2P update request message) to the logical block handler. For various example embodiments, operation 210 comprises adding the handler request to a queue (e.g., at the end of the queue) for the logical block handler. Eventually, the handler request can exit the queue and the handler request can be received by the logical block handler. Sending the handler request after the L2P journal entry is added can help avoid race conditions (which can lead to data loss) as described herein. The queue can have a depth of 32, and each handler request can comprise up to 32 entries, thereby enabling the queue to support 1024 outstanding L2P updates in flight. In response to the journal buffer being full, at operation 214, the processing device (e.g., 117) generates a journal buffer data dump of the journal buffer by emptying (e.g., flushing) data content of (e.g., journal entries stored in) the journal buffer into the journal buffer data dump. Additionally, at operation 216, the processing device (e.g., 117) adds the journal buffer data dump to a waitlist. For example, the waitlist can comprise a linked list. The journal buffer data dump can be added to the waitlist by adding, to the waitlist, a pointer to the journal buffer data dump. The journal buffer data dump can be stored on the volatile memory device (e.g., local memory 119) until it is stored on (e.g., persisted to) the non-volatile memory device (e.g., 130 or 140) .

[0046] After the logical block handler indicates that the journal buffer data dump is ready to be stored on the non-volatile memory device, at operation 222, the processing device (e.g., 117) causes the journal buffer data dump to be stored on the non-volatile memory device.

[0047] Referring now to FIG. 3, method 300 represents method 200 of FIG. 2 with additional operations. At operation 302, the processing device (e.g., 117) periodically stores each section of the plurality of sections of an L2P table to the non-volatile memory device as a section snapshot (e.g., different section snaps at different periods) . For some example embodiments, the L2P table of a memory system into portions or sections that are periodically stored (e.g., dumped) to the non-volatile memory (e.g., NAND-type memory device) as portion / section snapshots.

[0048] Operations 304, 306, 308, and 310 are respectively similar to operations 204, 206, 208, and 210 of method 200 described with respect to FIG. 2. At operation 312, the processing device (e.g., 117) monitors for when the journal buffer is full. In response to the journal buffer being full, method 300 proceeds to operations 314 and 316, which are respectively similar to operations 214 and 216 of method 200 described with respect to FIG. 2. Additionally, at operation 318, the processing device (e.g., 117) associates the journal buffer data dump (generated at operation 314)  with a select handler request corresponding to (or associated with) a last journal entry that was added to the journal buffer and that triggered the generating of the journal buffer data dump (at operation 314) . In this way, this journal buffer data dump can be related to the select handler request that triggers the journal buffer to be full.

[0049] During operation 320, the processing device (e.g., 117) receives an indication from the logical block handler that the journal buffer data dump is ready to be stored on the non-volatile memory device. For various example embodiments, the indication comprises a pointer to the select handler request associated with the journal buffer data dump at operation 318. For example, the select handler request can be stored on the volatile memory device, and the pointer can point to a memory location where the select handler request is stored on the volatile memory device. In response to receiving the indication at operation 320, method 300 proceeds to operation 322, where the processing device (e.g., 117) causes the journal buffer data dump to be stored on the non-volatile memory device.

[0050] FIG. 4 is a block diagram illustrating an example of sections of an L2P table of a memory system and a journal buffer data dump being stored (as persistent data content 400) on a non-volatile memory device of the memory system, in accordance with some example embodiments of the present disclosure. As described herein, a memory system (e.g., memory sub-system 110) can periodically (e.g., circularly) store each section of the plurality of sections to the non-volatile memory device as a section snapshot. This is represented by stored L2P section data 402, 406, 408, and 410. Additionally, to avoid potential data loss in the event of an unexpected power loss, journal buffer data dumps can also be stored (e.g., persisted to) on the non-volatile memory, where each journal buffer data dump can be generated when the journal buffer becomes full. This is represented by individual journal buffer data dump 404, which comprises journal entries 0 through N. According to various example embodiments, a journal buffer data dump is not written (e.g., programmed) to the non-volatile memory device until all L2P memory address update entries in a related / associated handler request (e.g., related / associated with the journal buffer data dump) are completed by a logical block handler (e.g., LBA handler) and the logical block handler has indicated (e.g., provided a response indicating) as such.

[0051] FIG. 5 is a diagram illustrating example operations 500 for performing a journal update prior to logical-to-physical memory address information update within an example memory system, in accordance with some example embodiments of the present disclosure. As shown, the example memory system comprises a slow volatile memory device 502, a fast volatile memory  device 504, a handler request queue 506, a logical block handler 508, a journal buffer data dump waitlist 510, and 1 non-volatile memory device 512. The handler request queue 506 is configured to store and queue one or more handler requests for the logical block handler 508, where handler request 524 represents an example handler request added to the handler request queue 506. Each handler request comprises one or more L2P update entries (e.g., max of 32 entries) , where each entry represents an L2P mapping update for the logical block handler 508 to implement. As shown, the handler request 524 comprises 32 L2P update entries (e.g., 0 through 31) , where each entry comprises a select logical memory address (e.g., LBA) and a select physical memory address (e.g., PBA) corresponding to the select logical memory address.

[0052] During operation 514, an L2P update request is generated or received (e.g., in response to a host command to write data to the memory system) and, in response, at operation 516, the memory system generates and adds an L2P update entry for the L2P update request to a handler request (e.g., L2P update entry 31 in handler request 524) . The handler request is eventually added to the handler request queue 506, thereby causing each L2P update entry of the handler request to be sent to the logical block handler 508 for processing. Depending on the example embodiment, the handler request queue 506 can be stored on the slow volatile memory device 502 or the fast volatile memory device 504. At operation 518, the memory system adds a journal entry to a journal buffer on the slow volatile memory device 502. According to some example embodiments, a select variable on the fast volatile memory device 504 is used for operations 516 and 518. For example, a global or stack variable with logical and physical memory addresses on the fast volatile memory device 504 can be used to generate and add the journal entry to the journal buffer on the slow volatile memory device 502 and used to add the L2P update entry to the handler request (e.g., handler request 524) , thereby permitting operations 516 and 518 to be performed in the same software context (e.g., API context) . After the journal entry is generated and added to the journal buffer and the L2P update entry is added to the handler request, the select variable no longer needs to be maintained (e.g., the logical and physical memory addresses for the select variable no longer need to be maintained) and can be released (without needing to wait until the logical block handler 508 completes the handler request and the L2P update entry therein) . By using a variable on the fast volatile memory device 504 (rather than a variable on the slow volatile memory device 502) , various example embodiments can save access time (e.g., around 80-100 ns) , which can be considerable / impactful time savings in memory systems that have a small margin of time per input / output (IO) operation (e.g., in a PCIe Generation 5 memory  system, the margin can be around 400ns) . Handler requests stored in the handler request queue 506 are delivered to and processed by the logical block handler 508 according to their respective order in the handler request queue 506.

[0053] Eventually, when the journal buffer on the slow volatile memory device 502 becomes full, at operation 520, the current data content of the journal buffer is emptied into a journal buffer data dump, and the generated journal buffer data dump is added to the journal buffer data dump waitlist 510. For some example embodiments, the journal buffer data dump is stored on the slow volatile memory device 502. Additionally, for some example embodiments, the journal buffer data dump is added to the journal buffer data dump waitlist 510 by adding a pointer to a memory location (e.g., on the slow volatile memory device 502) where the journal buffer data dump is stored. After the journal buffer data dump is added to the journal buffer data dump waitlist 510, the journal buffer data dump can remain on the journal buffer data dump waitlist 510 and is not stored on the non-volatile memory device 512 until the logical block handler 508 indicates that it is time to do so (e.g., when the logical block handler 508 indicates that all L2P updates associated with the journal buffer data dump have been completed by the 508) . To facilitate the eventual storage of the journal buffer data dump to the non-volatile memory device 512, the journal buffer data dump added to the journal buffer data dump waitlist 510 can be associated with a given handler request that caused the journal buffer to be full (e.g., the given handler request associated with / corresponding to the last journal entry added to the journal buffer prior to a dump) and that triggered the journal dump to be generated and added to the journal buffer data dump waitlist 510. For some example embodiments, this association is later used to facilitate (e.g., trigger) storage of the journal buffer data dump onto the non-volatile memory device 512.

[0054] The logical block handler 508 can be configured to generate a response 526 for each handler request it processes (e.g., completes) . For some example embodiments, a response for a select handler request comprises a pointer (or some other reference) associated with the select handler request. For example, the pointer can be the same pointer used in the handler request queue 506 to reference the select handler request when the select handler request was added to the handler request queue 506. The response provided by the logical block handler 508 can provide the memory system with an indication of when a corresponding journal buffer data dump added to the journal buffer data dump waitlist 510 can be stored to the non-volatile memory device 512. Accordingly, when the response 526 received from the logical block handler 508  indicates that a given handler request has been processed (e.g., completed) by the logical block handler 508, at operation 522, causes a journal buffer data dump associated with the given handler request to be stored on (e.g., saved to) the non-volatile memory device 512. In particular, the response 526 can comprise a pointer to the given handler request, the memory system can determine that the given handler request has been completed based on the pointer, and the memory system can determine (e.g., identify) which of (waitlisted) journal buffer data dumps on the journal buffer data dump waitlist 510 is associated with the given handler request based on handler requests respectively associated with each of those journal buffer data dump. The memory system can then cause the identified journal buffer data dump on the journal buffer data dump waitlist 510 to be stored on the non-volatile memory device 512.

[0055] FIG. 6 illustrates and describes an example timeline 610 of the operations of FIG. 5 being performed within a memory system (e.g., memory sub-system 110) , in accordance with some example embodiments of the present disclosure. In particular, FIG. 6 illustrates how various example embodiments can avoid race conditions issues that could otherwise exist in the memory system. In FIG. 6, the persistent data content 600 comprises sections of an L2P table of a memory system and a journal buffer data dump stored on a non-volatile memory device (e.g., 512) of the memory system (similar to the persistent data content 400 of FIG. 4) . Based on the operation timeline 610 shown, stored L2P section 1 data 602 is stored first on the non-volatile memory device, stored L2P section 2 data 604 is stored next on the non-volatile memory device, journal buffer data dump 606 is stored next on the non-volatile memory device, and stored L2P section 3 data 608 is stored last on the non-volatile memory device.

[0056] Prior to operation 612, the memory controller writes a snapshot of section 1 of the L2P table to the non-volatile memory device, thereby storing the snapshot as stored L2P section 1 data 602 on the non-volatile memory device. At operation 612, a memory controller (e.g., memory sub-system controller 115) of the memory system updates the journal buffer (on a volatile memory device) with journal entries n-1 and n, and this update occurs before corresponding L2P update requests (in a handler request) are sent to a logical block handler of the memory system. Eventually, at operation 614, the memory controller adds corresponding L2P update entries n-1 and n to a select handler request, and the select handler request is added to a queue (e.g., handler request queue 506) .

[0057] When the journal buffer is detected as full, instead of directly being stored on the non-volatile memory device (e.g., 512) , a journal buffer data dump is generated and added to a waitlist  (at operation 616) for eventual storage on (e.g., programming to) the non-volatile memory device. Additionally, the journal buffer data dump is associated (e.g., related) with the select handler request that caused the journal buffer to be full. In particular, the journal buffer data dump is associated with the select handler request that is associated with / corresponds to the last journal entry n added to the journal buffer prior to the dump. While the journal buffer data dump waits to be stored on the non-volatile memory device, at operation 618, the memory controller writes a snapshot of section 2 of the L2P table to the non-volatile memory device, thereby storing the snapshot as stored L2P section 2 data 604 on the non-volatile memory device. Eventually, at operation 620, the logical block handler finishes an L2P update according to the select handler request associated with journal entry n and indicates such to the memory controller (e.g., via response 526 that comprises a pointer to the select handler request) . In response to this indication from the logical block handler, at operation 622, the memory controller causes the journal buffer data dump that is on the waitlist and associated with the select handler request to be removed from the waitlist and written to the non-volatile memory device (as represented by journal buffer data dump 606) . In this way, various example embodiments can avoid a race condition where the journal buffer data dump 606 contains journal entries n-1 and n for section 2 of the L2P table, and the journal buffer data dump 606 is stored prior to section 2 of the L2P table (on volatile memory) being updated by the logical block handler, which can avoid a situation where a snapshot of section 2 of the L2P table that contains L2P data older than the journal buffer data dump 606 (data not updated according to the select handler request corresponding to journal entries n-1 and n) being stored on the non-volatile memory device after the journal buffer data dump 606. If the snapshot of section 2 of the L2P table was stored after the journal buffer data dump 606, the newer L2P data of the journal buffer data dump 606 would be disregarded in favor of the older data of the snapshot of section 2, thereby resulting in loss of data.

[0058] FIG. 7 illustrates an example machine in the form of a computer system 700 within which a set of instructions can be executed for causing the machine to perform any one or more of the methodologies discussed herein. In some example embodiments, the computer system 700 can correspond to a host system (e.g., the host system 120 of FIG. 1) that includes, is coupled to, or utilizes a memory sub-system (e.g., the memory sub-system 110 of FIG. 1) or can be used to perform the operations described herein. In alternative example embodiments, the machine can be connected (e.g., networked) to other machines in a local area network (LAN) , an intranet, an extranet, and / or the Internet. The machine can operate in the capacity of a server or a client  machine in a client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or a client machine in a cloud computing infrastructure or environment.

[0059] The machine can be a personal computer (PC) , a tablet PC, a set-top box (STB) , a Personal Digital Assistant (PDA) , a cellular telephone, a web appliance, a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0060] The example computer system 700 includes a processing device 702, a main memory 704 (e.g., ROM, flash memory, DRAM such as SDRAM or Rambus DRAM (RDRAM) , etc. ) , a static memory 706 (e.g., flash memory, static random access memory (SRAM) , etc. ) , and a data storage device 710, which communicate with each other via a bus 718.

[0061] The processing device 702 represents one or more general-purpose processing devices such as a microprocessor, a central processing unit, or the like. More particularly, the processing device 702 can be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing other instruction sets, or processors implementing a combination of instruction sets. The processing device 702 can also be one or more special-purpose processing devices such as an application-specific integrated circuit (ASIC) , a field programmable gate array (FPGA) , a digital signal processor (DSP) , a network processor, or the like. The processing device 702 is configured to execute instructions 716 for performing the operations and steps discussed herein. The computer system 700 can further include a network interface device 708 to communicate over a network 712.

[0062] The data storage device 710 can include a machine-readable storage medium 714 (also known as a computer-readable medium) on which is stored one or more sets of instructions 716 or software embodying any one or more of the methodologies or functions described herein. The instructions 716 can also reside, completely or at least partially, within the main memory 704 and / or within the processing device 702 during execution thereof by the computer system 700, the main memory 704 and the processing device 702 also constituting machine-readable storage  media. The machine-readable storage medium 714, data storage device 710, and / or main memory 704 can correspond to the memory sub-system 110 of FIG. 1.

[0063] In one example embodiment, the instructions 716 include instructions to implement functionality corresponding to performing a journal update prior to logical-to-physical memory address information update on a memory sub-system as described herein (e.g., the journal entry generator 113 of FIG. 1) . While the machine-readable storage medium 714 is shown in an example embodiment to be a single medium, the term “machine-readable storage medium” should be taken to include a single medium or multiple media that store the one or more sets of instructions. The term “machine-readable storage medium” shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term “machine-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.

[0064] Described implementations of the subject matter can include one or more features, alone or in combination as illustrated below by way of examples.

[0065] Example 1 is a memory system comprising: a volatile memory device; a non-volatile memory device; and a processing device, operatively coupled to the volatile memory device and the non-volatile memory device, configured to perform operations comprising: receiving a logical-to-physical (L2P) memory address update request; adding an L2P memory address update entry, for the L2P memory address update request, to a handler request for a logical block handler, the logical block handler being configured to update an L2P table on the volatile memory device based on the handler request, the L2P table comprising information that maps logical memory addresses to physical memory addresses on the memory system; adding an L2P journal entry, for the L2P memory address update request, to a journal buffer on the volatile memory device; sending the handler request to the logical block handler; in response to the journal buffer being full: generating a journal buffer data dump of the journal buffer by emptying data content of the journal buffer into the journal buffer data dump; and adding the journal buffer data dump to a waitlist; and after the logical block handler indicates that the journal buffer data dump is ready to be stored on the non-volatile memory device, causing the journal buffer data dump to be stored on the non-volatile memory device.

[0066] In Example 2, the subject matter of Example 1 includes, wherein the L2P table comprises a plurality of sections, and wherein the operations comprise: periodically storing each section of the plurality of sections to the non-volatile memory device as a section snapshot.

[0067] In Example 3, the subject matter of Examples 1–2 includes, wherein the operations comprise: receiving an indication from the logical block handler that the journal buffer data dump is ready to be stored on the non-volatile memory device.

[0068] In Example 4, the subject matter of Example 3 includes, wherein the handler request is an individual handler request, wherein the L2P journal entry is an individual L2P journal entry, and wherein the operations comprising: in response to the journal buffer being full, associating the journal buffer data dump with a select handler request, the select handler request corresponding to a last journal entry that was added to the journal buffer and that triggered the generating of the journal buffer data dump, the indication comprising a pointer to the select handler request.

[0069] In Example 5, the subject matter of Examples 1–4 includes, wherein the sending of the handler request to the logical block handler comprises: adding the handler request to a request queue for the logical block handler.

[0070] In Example 6, the subject matter of Examples 1–5 includes, wherein the handler request comprises a plurality of L2P memory address update entries.

[0071] In Example 7, the subject matter of Examples 1–6 includes, wherein the operations comprise: monitoring for when the journal buffer is full.

[0072] Example 8 is a method to implement any of Examples 1–7.

[0073] Example 9 is at least one machine-readable medium comprising instructions that, when executed by a processing device of a memory system, cause the processing device to perform operations to implement any of Examples 1–7.

[0074] Some portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or  magnetic signals capable of being stored, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0075] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure can refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage systems.

[0076] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus can be specially constructed for the intended purposes, or it can include a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can be stored in a computer-readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.

[0077] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems can be used with programs in accordance with the teachings herein, or it can prove convenient to construct a more specialized apparatus to perform the method. The structure for a variety of these systems will appear as set forth in the description below. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages can be used to implement the teachings of the disclosure as described herein.

[0078] The present disclosure can be provided as a computer program product, or software, that can include a machine-readable medium (such as a non-transitory machine-readable medium) having stored thereon instructions, which can be used to program a computer system (or other electronic devices) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer) . In some example embodiments, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., a computer) readable storage medium such as a ROM, RAM, magnetic disk storage media, optical storage media, flash memory components, and so forth. A  machine-readable storage medium can be non-transitory (in other words, not having any transitory signals) in that it does not embody a propagating signal. However, labeling a machine-readable storage medium “non-transitory” should not be construed to mean that the machine-readable storage medium is incapable of movement; the machine-readable storage medium should be considered as being transportable from one physical location to another.

[0079] In the foregoing specification, example embodiments of the disclosure have been described with reference to specific example embodiments thereof. It will be evident that various modifications can be made thereto without departing from the broader spirit and scope of example embodiments of the disclosure as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Claims

1.A memory system comprising:a volatile memory device;a non-volatile memory device; anda processing device, operatively coupled to the volatile memory device and the non-volatile memory device, configured to perform operations comprising:receiving a logical-to-physical (L2P) memory address update request;adding an L2P memory address update entry, for the L2P memory address update request, to a handler request for a logical block handler, the logical block handler being configured to update an L2P table on the volatile memory device based on the handler request, the L2P table comprising information that maps logical memory addresses to physical memory addresses on the memory system;adding an L2P journal entry, for the L2P memory address update request, to a journal buffer on the volatile memory device;sending the handler request to the logical block handler;in response to the journal buffer being full:generating a journal buffer data dump of the journal buffer by emptying data content of the journal buffer into the journal buffer data dump; andadding the journal buffer data dump to a waitlist; andafter the logical block handler indicates that the journal buffer data dump is ready to be stored on the non-volatile memory device, causing the journal buffer data dump to be stored on the non-volatile memory device.2.The memory system of claim 1, wherein the L2P table comprises a plurality of sections, and wherein the operations comprise:periodically storing each section of the plurality of sections to the non-volatile memory device as a section snapshot.3.The memory system of claim 1, wherein the operations comprise:receiving an indication from the logical block handler that the journal buffer data dump is ready to be stored on the non-volatile memory device.4.The memory system of claim 3, wherein the handler request is an individual handler request, wherein the L2P journal entry is an individual L2P journal entry, and wherein the operations comprising:in response to the journal buffer being full, associating the journal buffer data dump with a select handler request, the select handler request corresponding to a last journal entry that was added to the journal buffer and that triggered the generating of the journal buffer data dump, the indication comprising a pointer to the select handler request.5.The memory system of claim 1, wherein the sending of the handler request to the logical block handler comprises:adding the handler request to a request queue for the logical block handler.6.The memory system of claim 1, wherein the handler request comprises a plurality of L2P memory address update entries.7.The memory system of claim 1, wherein the operations comprise:monitoring for when the journal buffer is full.8.The memory system of claim 1, wherein the logical memory addresses are logical block addresses (LBAs) and the physical memory addresses are physical block addresses (PBAs) .9.At least one non-transitory machine-readable storage medium comprising instructions that, when executed by a processing device of a memory system, cause the processing device to perform operations comprising:receiving a logical-to-physical (L2P) memory address update request;adding an L2P memory address update entry, for the L2P memory address update request, to a handler request for a logical block handler, the logical block handler being configured to update an L2P table on a volatile memory device of the memory system based on the handler request, the L2P table comprising information that maps logical memory addresses to physical memory addresses on the memory system;adding an L2P journal entry, for the L2P memory address update request, to a journal buffer on the volatile memory device;sending the handler request to the logical block handler;in response to the journal buffer being full:generating a journal buffer data dump of the journal buffer by emptying data content of the journal buffer into the journal buffer data dump; andadding the journal buffer data dump to a waitlist; andafter the logical block handler indicates that the journal buffer data dump is ready to be stored on a non-volatile memory device of the memory system, causing the journal buffer data dump to be stored on the non-volatile memory device.10.The at least one non-transitory machine-readable storage medium of claim 9, wherein the L2P table comprises a plurality of sections, and wherein the operations comprise:periodically storing each section of the plurality of sections to the non-volatile memory device as a section snapshot.11.The at least one non-transitory machine-readable storage medium of claim 9, wherein the operations comprise:receiving an indication from the logical block handler that the journal buffer data dump is ready to be stored on the non-volatile memory device.12.The at least one non-transitory machine-readable storage medium of claim 11, wherein the handler request is an individual handler request, wherein the L2P journal entry is an individual L2P journal entry, and wherein the operations comprising:in response to the journal buffer being full, associating the journal buffer data dump with a select handler request, the select handler request corresponding to a last journal entry that was added to the journal buffer and that triggered the generating of the journal buffer data dump, the indication comprising a pointer to the select handler request.13.The at least one non-transitory machine-readable storage medium of claim 9, wherein the sending of the handler request to the logical block handler comprises:adding the handler request to a request queue for the logical block handler.14.The at least one non-transitory machine-readable storage medium of claim 9, wherein the handler request comprises a plurality of L2P memory address update entries.15.The at least one non-transitory machine-readable storage medium of claim 9, wherein the operations comprise:monitoring for when the journal buffer is full.16.The at least one non-transitory machine-readable storage medium of claim 9, wherein the logical memory addresses are logical block addresses (LBAs) and the physical memory addresses are physical block addresses (PBAs) .17.A method comprising:receiving, by a processing device of a memory system, a logical-to-physical (L2P) memory address update request;adding, by the processing device, an L2P memory address update entry, for the L2P memory address update request, to a handler request for a logical block handler, the logical block handler being configured to update an L2P table on a volatile memory device of the memory system based on the handler request, the L2P table comprising information that maps logical memory addresses to physical memory addresses on the memory system;adding, by the processing device, an L2P journal entry, for the L2P memory address update request, to a journal buffer on the volatile memory device;sending, by the processing device, the handler request to the logical block handler;in response to the journal buffer being full:generating, by the processing device, a journal buffer data dump of the journal buffer by emptying data content of the journal buffer into the journal buffer data dump; andadding, by the processing device, the journal buffer data dump to a waitlist; andafter the logical block handler indicates that the journal buffer data dump is ready to be stored on a non-volatile memory device of the memory system, causing, by the processing device, the journal buffer data dump to be stored on the non-volatile memory device.18.The method of claim 17, wherein the L2P table comprises a plurality of sections, and wherein the method comprises:periodically, by the processing device, storing each section of the plurality of sections to the non-volatile memory device as a section snapshot.19.The method of claim 17, comprising:receiving an indication from the logical block handler that the journal buffer data dump is ready to be stored on the non-volatile memory device.20.The method of claim 17, wherein the sending of the handler request to the logical block handler comprises:adding the handler request to a request queue for the logical block handler.

Images