Virtual Storage Controller Transaction Log State Preservation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Virtual storage controllers in storage fabrics lack access to non-volatile memory, leading to expensive synchronous flushing of transaction logs, which limits write operation speed and complicates state preservation across failures.
Innovation Solution
The virtual storage controller asynchronously stores a transaction log in volatile memory and then flushes it to a stable storage device upon detecting a failure, allowing for state preservation and replay of transactions upon reboot, even without access to non-volatile host device memory.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If synchronous flushing of transaction log to persistent storage is used, then data reliability is improved, but write operation speed deteriorates
Solution Approach 1:
The system performs preliminary actions by maintaining a transaction log in volatile memory before failures occur, allowing the log to be flushed to persistent storage asynchronously after the failure rather than synchronously during write operations. This preliminary preparation enables fast writes while ensuring data can be recovered after failure.
Solution Approach 2:
The patent introduces an intermediary mechanism - a transaction log structure that acts as a buffer between the volatile memory and persistent storage. This intermediary allows the system to decouple the speed of volatile memory writes from the reliability of persistent storage, enabling fast writes to the log while periodically flushing to stable storage for reliability.
2Reliability
If non-volatile memory is used in virtual storage controller, then state preservation across failure is improved, but device complexity and access difficulty worsen
Solution Approach 1:
The patent uses stable storage devices as intermediaries between the virtual storage controller and the need for persistent state preservation. Instead of embedding non-volatile memory in the virtual storage controller, the system mediates through external stable storage devices that the controller can access, simplifying the controller's internal complexity while still achieving state preservation.
Solution Approach 2:
The system creates copies of the transaction log from volatile memory to stable storage devices. This copying mechanism allows the virtual storage controller to maintain its simple volatile memory architecture while preserving state by copying critical data to persistent external storage, avoiding the need for complex integrated non-volatile memory solutions.
3Productivity
If asynchronous flushing to stable storage is used, then write operation speed is improved, but data loss risk worsens
Solution Approach 1:
The system performs preliminary actions by continuously maintaining the transaction log in volatile memory with frequent updates, so that even with asynchronous flushing, the most recent state is preserved. This preliminary maintenance of current state in fast memory reduces data loss risk while allowing asynchronous flushing to improve write speed.
Solution Approach 2:
The patent implements periodic action by flushing the transaction log from volatile memory to stable storage at regular intervals or under specific conditions (such as when full). This periodic flushing balances the need for fast writes with the need for data safety, reducing data loss risk while maintaining high write performance between flushes.
Data Source
AI summary
A method, non-transitory computer readable medium, and computing device that determines when a software failure associated with a virtual storage controller has occurred. At least a portion of a transaction log corresponding to the virtual storage controller is stored in a stable storage device, when the determining indicates that the software failure associated with the virtual storage controller has occurred. A determination is made when the virtual storage controller has rebooted. The at least a portion of the transaction log is retrieved from the stable storage device, when the determining indicates that the virtual storage controller has rebooted. Thereby, state can be preserved and transactions pending, but not yet committed to storage server devices, can be replayed and proceed with minimal or no impact on the client devices originating the transactions.