Request Identifier for Safe Storage Failure Recovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In clustered environments, applications experience delays or failures when communication with a storage system is lost due to failures like server reboots or file system dismounts, leading to uncertainty about data integrity upon reconnection.
Innovation Solution
The system employs a request identifier stored in persistent storage to ensure data integrity by allowing applications to resume communication only if the data has not been modified, using notifications and resume requests to verify the data's state.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If the application continues execution after a storage system failure, then productivity is maintained, but data integrity cannot be ensured
Solution Approach 1:
The system performs preliminary actions by storing the request identifier in persistent storage before the failure occurs. This allows the application to later verify whether the target data has been modified since the original access request, enabling safe resumption of execution only when data integrity is confirmed.
Solution Approach 2:
The system implements feedback by checking whether the stored request identifier still matches the current state of the target data. This feedback mechanism allows the application to determine if the data has been modified and adjust its execution accordingly, ensuring data integrity while maintaining productivity.
2Reliability
If the application pauses execution during a failure, then data integrity can be verified, but execution delays increase
Solution Approach 1:
Instead of pausing the entire application execution, the system performs a partial verification action by checking only the request identifier against the current data state. This minimal verification approach ensures data integrity while minimizing execution delays, as the check is much faster than a full data validation process.
3Productivity
If the application assumes data has not changed after reconnection, then execution delays are reduced, but data integrity cannot be guaranteed
Solution Approach 1:
The system performs preliminary verification by checking the request identifier stored in persistent storage against the current state of the target data before the application resumes execution. This preliminary check ensures data consistency while allowing rapid resumption of operations, as the verification is performed only once upon reconnection rather than continuously during execution.
Data Source
AI summary
A request identifier is employed with various systems and methods in order to enable an application to pause execution during a failure and subsequently resume execution and communication with a storage system once the failure is resolved. An application residing on a node may attempt to access target data on a storage system. The application sends a request to access the target data. The request may be associated with a request identifier that identifies the application. When the storage system experiences a failure, the application receives a failure notification. The application pauses execution as a result of the notification. When the node reestablishes a connection to the storage system, the application resumes execution using the same request identifier. If the resume request is granted, the application is guaranteed that the target data was not modified during the failure.