Log-Based Block Cache De-Staging with Overlapping Write Merge
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional log-based write cache methods in virtualized computing environments suffer from inefficiencies such as increased CPU usage, resource contention, and write amplification due to sequential processing and inadequate utilization of backend storage queue depth, leading to suboptimal performance in accessing storage devices.
Innovation Solution
Implementing a logical data structure for merging logs, using single producer single consumer (SPSC) and single producer multiple consumer (SPMC) thread models, and employing a two skip-list-based data structure for efficient I/O operations, along with range sort algorithms to optimize I/O requests and reduce memory copy operations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If sequential log de-staging is used to avoid backend storage queue overlap, then data integrity is maintained, but I/O throughput deteriorates due to queue depth underutilization
Solution Approach 1:
The system dynamically adjusts de-staging strategies based on backend storage queue status. When queues are available, parallel de-staging is enabled to maximize throughput. When overlap is detected or queues are full, the system transitions to sequential processing to maintain data integrity, creating a dynamic adaptation between reliability and productivity modes.
Solution Approach 2:
The system changes the processing parameter from strictly sequential to parallel based on backend storage conditions. By monitoring queue depth and availability, the system adjusts the de-staging mode parameter, allowing it to optimize between throughput (parallel) and reliability (sequential) depending on real-time storage system state.
2Adaptability or versatility
If LSM-tree based storage with additional backend tasks is used, then storage functionality is enhanced, but CPU usage increases due to additional threads
Solution Approach 1:
The patent extracts the log de-staging function from the traditional LSM-tree backend task structure. By separating de-staging as an independent operation that can proceed in parallel with other backend tasks, the system reduces CPU contention while maintaining enhanced storage functionality. This extraction allows log processing to occur independently without requiring additional threads in the traditional LSM-tree hierarchy.
Solution Approach 2:
The system maintains continuous log de-staging operations that run concurrently with other backend tasks. Rather than pausing log processing to perform other LSM-tree operations, the system enables continuous useful action by allowing multiple backend tasks to execute in parallel, reducing overall CPU idle time while maintaining full storage functionality.
3Productivity
If log merging is performed to utilize backend storage queue depth, then I/O efficiency is improved, but write amplification occurs due to persistent merged log tables
Solution Approach 1:
The system performs partial log merging only when beneficial for queue utilization, rather than always merging all logs. By selectively merging logs based on queue depth and overlap conditions, the system achieves I/O efficiency improvements without the excessive write amplification that would result from universal log merging. This partial action approach balances productivity gains against substance loss.
4Productivity
If multiple dispatcher threads are used to scale I/O operations, then throughput is improved, but interrupt overhead increases reducing efficiency
Solution Approach 1:
The system segments the dispatcher functionality into specialized threads with specific responsibilities. By dividing I/O dispatching into distinct segments (e.g., log de-staging dispatchers, backend task dispatchers), the system can optimize each segment to minimize interrupt overhead while maintaining high throughput. This segmentation allows for more efficient thread management compared to a monolithic dispatcher approach.
Data Source
Figure 1
Figure 2A~2D
Figure 2E
AI summary
Requests for a write storage operation are stored in a ring buffer. The next available request is retrieved from the ring buffer. When the next available request comprises a write operation that overlaps in a logical address range with a previous request stored in the ring buffer, the next available request is suspended. The next available request and the previous request are merged to generate a single request that includes logical address ranges of the next available request and the previous request.