Fault-Tolerant File Replication via Concurrent Block Updates
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional fault-tolerant file replication systems are inefficient due to sequential writing of changes, requiring two independent I/O operations for each update, which increases storage and processing burdens and does not exploit concurrent execution capabilities of storage devices.
Innovation Solution
A system that identifies primary and secondary replica files, allowing concurrent processing and direct modification of replicas, with a processor that receives requests, updates local and remote replica files, and ensures replication success by matching responses against a quorum value, thereby minimizing storage and processing loads.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional replication mechanisms write changes sequentially to persistent logs and then to replica files, then data consistency is maintained, but storage devices face additional storage and processing burdens and cannot exploit concurrent execution capabilities
Solution Approach 1:
The patent segments the file into multiple independent parts or blocks that can be updated concurrently. Instead of treating the entire file as a single sequential update unit, each block can be replicated and updated independently across multiple storage devices, enabling parallel processing while maintaining overall data consistency through version control and conflict resolution mechanisms.
Solution Approach 2:
The patent implements preliminary actions by maintaining persistent logs that record all changes before they are applied to replica files. This allows the system to pre-process and queue updates, then apply them concurrently to multiple replicas using techniques like vector clocks and conflict-free replicated data types (CRDTs), rather than strictly sequential application.
2Reliability
If traditional replication mechanisms require two independent I/O operations for each update (once to persistent log, second time to replica file), then data integrity is ensured, but storage and processing burdens increase
Solution Approach 1:
The patent merges the persistent log and replica file update operations into a single coordinated I/O operation. By using distributed transaction protocols and atomic commit mechanisms, the system ensures that both the log and the replica file are updated together in one atomic operation, eliminating the need for two separate I/O operations while maintaining data integrity through rollback capabilities if the operation fails.
Solution Approach 2:
The patent uses copying techniques where the persistent log structure is replicated across multiple storage devices in the same manner as the actual file data. This allows each storage device to have both the log and data copies locally, enabling concurrent updates without centralized coordination overhead and reducing the burden on any single device.
3Productivity
If traditional replication systems update the persistent log first and then update the replica file at a later time, then processing load is reduced, but the system must consult the persistent log each time the replica is accessed to ensure up-to-date data
Solution Approach 1:
The patent implements feedback mechanisms through version vectors and timestamps that are embedded with each data block and log entry. When a replica is accessed, the system checks these version indicators to determine if the local copy is up-to-date without needing to consult the persistent log. If the version matches, the data is considered current; if not, the system knows to fetch updates, eliminating continuous log consultation while ensuring data freshness.
Data Source
AI summary
Systems and methods are provided for fault-tolerant file replication. A request including an operation and a file identifier is received. It is determined if the operation is of a predetermined type of operations. If the operation is of a predetermined type of operation, a target local replica file is identified. It is determined whether the target local replica file is a primary replica. If the target local replica file is the primary replica, the operation included in the request is executed. Otherwise, one or more of the set of storage devices on which remote replica files associated with the file identifier are stored are identified. In turn, the remote replica file that is the primary replica is identified. The request is transmitted to storage device on which the identified remote replica file that is the primary replica is stored.