NVM Update Layer Retention to Reduce Consolidation Latency

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing data storage systems face inefficiencies in consolidation processes after sequential writes, leading to a high number of back-to-back consolidations and performance degradation due to immediate erasure of update layer entries, which affects read performance and increases latency.

Innovation Solution

Implement a delayed copy-back mechanism where update layer entries are not immediately erased after consolidation, allowing some data to remain in the update layer for future read operations, and utilize a bitmap to track these entries for efficient space management.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If data in the update layer is immediately erased after consolidation, then storage space is freed efficiently, but read performance deteriorates due to frequent re-copying operations

Engineering Contradiction:
Improveconsolidation efficiencyVSAvoidread performance
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent applies preliminary action by maintaining data in the update layer before consolidation is complete. The controller keeps a copy of data in the update layer and only erases it after confirming that the master layer has been successfully updated, allowing read operations to access the data without requiring immediate re-copying. This preliminary retention of data resolves the contradiction by ensuring read performance while still achieving space efficiency.

Inventive Principle:
Principle #10Preliminary action

2Quantity of substance

If all data in the update layer is erased after consolidation, then space is maximized for new data, but unnecessary consolidations increase latency

Engineering Contradiction:
Improveavailable storage spaceVSAvoidconsolidation latency
Core Design Contradiction:
Quantity of substanceVSLoss of time

Solution Approach 1:

The patent applies partial action by selectively erasing only the data in the update layer that has been successfully consolidated to the master layer, while retaining data that may still be needed for read operations. The controller tracks which data has been consolidated and erases only that portion, avoiding unnecessary erasure of data that might be read soon. This partial erasure approach reduces unnecessary consolidations and latency while still maximizing available space.

Inventive Principle:
Principle #16Partial or excessive action

3Reliability

If the update layer maintains all data for read operations, then read performance is improved, but the number of back-to-back consolidations increases

Engineering Contradiction:
Improveread performanceVSAvoidconsolidation frequency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent applies feedback by implementing a tracking mechanism that monitors which data in the update layer has been consolidated to the master layer. The controller uses this feedback information to determine which data can be safely erased and which should be retained. This feedback loop allows the system to maintain read performance by keeping necessary data while reducing consolidation frequency by erasing only consolidated data, thus resolving the contradiction between read performance and consolidation frequency.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS12625632B2Data retention for efficient consolidation processing in NVM
Publication Date: 2026.05.12 SANDISK TECHNOLOGIES LLC
  • US12625632B2 patent drawing
  • US12625632B2 patent drawing
  • US12625632B2 patent drawing

AI summary

When performing a consolidation process, entries (uRuns) in the update region (uRegion) of an update layer (uLayer) are typically erased immediately after the data in the uRuns is updated to a master layer (mLayer). The data may, at a later time, be copied back to the uRuns for read purposes. Rather than erasing the uRuns and then copying the data back to the uRuns for read purposes, the uRuns can simply not be erased after the consolidation. If space is needed, the uRuns can be erased without any need for consolidation. Furthermore, if another consolidation process occurs, the uRuns that were previously consolidated, but not erased, can simply be erased.