SSD Controller Execution Time Tagging for Emergency Read Priority
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In solid-state drives (SSDs), emergency read requests are often delayed due to the longer execution times of write and erase operations, which can lead to significant delays in processing IO requests, especially when these operations are queued together with read requests.
Innovation Solution
A method is introduced where an execution time is added to each IO request, allowing the SSD to prioritize and complete emergency requests within this time frame, with optional timeout indications and type-based execution time settings to manage different types of IO requests effectively.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If write and erase operations are executed in queue order, then operation reliability is maintained, but read request delay increases significantly
Solution Approach 1:
The patent implements dynamic request scheduling that adjusts execution priorities based on request types and timing. Emergency read requests can preempt or interrupt ongoing write/erase operations, while normal requests maintain FIFO ordering. This dynamic adjustment resolves the contradiction by allowing time-critical operations to break the strict reliability-based queue order when necessary.
Solution Approach 2:
The patent introduces execution time parameters and timeout indications for different request types. By assigning different time constraints and priorities to read, write, and erase operations, the system can dynamically adjust scheduling behavior. Emergency reads with short timeout parameters can override longer-duration write/erase operations, balancing reliability with time sensitivity.
2Reliability
If garbage collection and preventive maintenance operations are performed, then storage device reliability is improved, but IO request processing delay increases
Solution Approach 1:
The patent segments maintenance operations (garbage collection, preventive maintenance) into background tasks that run independently from the main IO request queue. These maintenance operations are scheduled during idle periods or low-utilization windows, allowing them to improve reliability without blocking time-critical IO requests. The segmentation separates concern between maintenance reliability and IO responsiveness.
Solution Approach 2:
The patent performs preliminary maintenance actions by pre-allocating maintenance windows and preparing storage blocks for garbage collection before they are needed. By proactively managing storage health in advance rather than reactively during IO bursts, the system maintains reliability while minimizing impact on IO request processing delays.
3Reliability
If sequential execution of write and erase operations is maintained, then data integrity is ensured, but emergency read request processing is delayed
Solution Approach 1:
The patent implements dynamic interrupt mechanisms that allow emergency read requests to preempt ongoing write/erase sequences when timing constraints are violated. The system monitors execution progress and can dynamically interrupt non-critical operations to service time-sensitive reads, then resume interrupted operations later, maintaining data integrity while improving emergency response speed.
Solution Approach 2:
The patent uses timeout indications and execution time monitoring as feedback mechanisms to detect when emergency reads are being delayed. When feedback indicates timing violations, the system adjusts scheduling priorities to interrupt or postpone write/erase operations, ensuring that data integrity is maintained through proper sequencing while preventing excessive delays for time-critical operations.
Data Source
AI summary
Embodiments of the present disclosure provide a data processing method, a controller, a storage device, and a storage system. The controller adds an execution time of an IO request to the IO request, and the execution time is used to instruct the storage device to complete the IO request before the execution time expires. The controller sends, to the storage device, the IO request to which the execution time is added. When receiving the IO request, the storage device can execute the IO request based on the execution time of the IO request.