SSD Firmware Table Rebuild via System Journaling
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional SSDs face inefficiencies in data management due to the large Logical-to-Physical (L2P) map table, which requires frequent updates and storage in volatile memory, leading to high overhead and slow startup times, as well as dual file systems for firmware and user data that increase complexity and overhead.
Innovation Solution
The introduction of a System Journal (S-Journal) mechanism that allows for partial updates and storage in non-volatile memory, reducing the need for frequent updates of the entire L2P map table and enabling efficient reconstruction upon power loss, along with Firmware Journals for managing firmware table updates, which reduces Write Amplification and facilitates power-safe data storage.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the entire L2P map table is saved to non-volatile memory whenever an update occurs, then data consistency is maintained, but write amplification increases and storage efficiency decreases
Solution Approach 1:
The L2P map table is divided into multiple segments or chunks that can be independently managed. Instead of treating the entire table as a single unit, the system can update and save only the modified segments to non-volatile memory, reducing write amplification while maintaining data consistency for updated portions.
Solution Approach 2:
The patent implements partial updates by identifying and saving only the specific portions of the L2P map table that have changed since the last save operation. This selective approach avoids the excessive action of saving the entire table, thereby reducing unnecessary write operations to non-volatile memory.
2Speed
If the large L2P map table is held in external DRAM, then fast access is enabled, but startup time increases due to the need to restore the entire table
Solution Approach 1:
The L2P map table is segmented into multiple sections that can be independently loaded into DRAM. During startup, only the necessary segments need to be restored, significantly reducing startup time while maintaining fast access performance for the loaded portions.
Solution Approach 2:
Instead of restoring the entire L2P map table during startup, the system performs partial restoration by loading only the segments that contain valid or frequently accessed data. This selective loading approach dramatically reduces startup time while preserving access speed for operational data.
3Adaptability or versatility
If random writing occurs in the L2P map table, then data updates are flexible, but the entire table must be saved even though only one entry changes
Solution Approach 1:
The L2P map table is organized into segments that can be independently updated and saved. When random writing occurs, only the specific segment containing the modified entry is identified and saved, maintaining update flexibility while improving storage efficiency by avoiding unnecessary saves of unchanged segments.
Solution Approach 2:
The system performs partial saves by identifying only the specific entries or segments that have been modified since the last save operation. This approach maintains the flexibility of random writing while dramatically improving storage efficiency by saving only the necessary portions rather than the entire table.
4Reliability
If firmware information is stored in a separate Firmware File System, then firmware data management is isolated, but system overhead increases and coherency challenges arise
Solution Approach 1:
The patent merges the firmware file system with the user data file system into a unified file system structure. This integration eliminates the need for separate management mechanisms, reducing system overhead and complexity while maintaining proper data isolation through logical separation within the unified system. Coherency is maintained through consistent file system operations across both firmware and user data.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A data storage device comprises a plurality of non-volatile memory devices configured to store a plurality of physical pages; a controller coupled to the plurality of memory devices that is configured to program data to and read data from the plurality of memory devices. A volatile memory may be coupled to the controller and may be configured to store a firmware table comprising a plurality of firmware table entries. The controller may be configured to maintain a plurality of firmware journals in the non-volatile memory devices. Each of the firmware journals may be associated with a firmware table entry and may comprise firmware table entry information. The controller may be configured to read the plurality of firmware journals upon startup and rebuild the firmware table using the firmware table entry information in each of the read plurality of firmware journals.