SSD Garbage Collection via Delayed Program Operations
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In distributed storage systems, the Program/Erase (P/E) cycle in Solid State Drives (SSDs) causes significant latency for write requests due to the need for garbage collection, which interferes with read and write operations, especially during heavy workloads.
Innovation Solution
Implementing a delayed Program operation strategy where the Program operation is deferred until a more convenient time, such as when the I/O load is low or sufficient time has passed since the last garbage collection, allowing only the Erase operation to proceed initially, thereby reducing latency.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If garbage collection is performed by copying valid pages before erasing blocks, then data integrity is maintained, but write request latency increases significantly
Solution Approach 1:
The system performs preliminary validation checks before initiating garbage collection. The host verifies which pages are valid and which blocks need erasure in advance, allowing the SSD to skip unnecessary Program operations and proceed directly to Erase operations, thereby reducing write request latency while maintaining data integrity
Solution Approach 2:
The host machine receives feedback from the SSD about which blocks require garbage collection and validates the necessary Program operations. This feedback mechanism allows the host to coordinate with the SSD, performing validation externally and enabling the SSD to focus on Erase operations, reducing the overall latency impact on write requests
2Quantity of substance
If garbage collection is performed frequently to reclaim space, then storage capacity is maintained, but interference with read and write requests increases
Solution Approach 1:
The system dynamically adjusts the garbage collection strategy based on current I/O workload conditions. When I/O load is high, the host performs validation externally and the SSD performs only Erase operations. When I/O load is low, the system can perform full Program/Erase cycles. This dynamic adaptation reduces interference with read and write requests while maintaining storage capacity
Solution Approach 2:
The system changes the operational parameters of garbage collection based on system state. The type of garbage collection (full Program/Erase vs. Erase-only) is adjusted as a parameter based on I/O load conditions, allowing the system to optimize between storage capacity reclamation and I/O throughput at different times
3Reliability
If the Program operation is performed before Erase in garbage collection, then valid data is preserved, but additional latency is incurred beyond the Erase operation
Solution Approach 1:
The system extracts the validation function from the SSD's internal garbage collection process and performs it externally at the host. This allows the SSD to perform only the Erase operation without the Program operation, reducing latency. The host separately handles the coordination of valid data preservation through validation feedback
Solution Approach 2:
The host machine acts as an intermediary between the data validation process and the SSD's Erase operation. The host validates which pages are valid and coordinates with the SSD, allowing the SSD to perform Erase operations without first performing Program operations, thereby reducing latency while the host ensures valid data preservation through its validation process
Data Source
AI summary
A Solid State Drive (SSD) (110) is disclosed. The SSD (110) may include storage (218) for data, and reception circuitry (203) to receive various instructions and data. The reception circuitry (203) may receive an instruction (257) from a host machine (105) to perform garbage collection, along with a selected P/E strategy (260). The SSD (110) may include garbage collection logic (209) to perform garbage collection, possibly with a delayed Program operation if an adaptive P/E strategy (1110) is selected. The SSD (110) may also include a mapping table (221) that may identify which pages were not Programmed before victim blocks (233, 236) were erased, and therefore require replication during a delayed Program operation.