Block Storage Relocation via Translation Table on Disk Failure

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional storage systems face inefficiencies in data recovery and resource management when a disk drive fails, leading to significant resource intensive replication processes, errors, and downtime, especially in cloud computing environments where data is redundantly stored across multiple disks.

Innovation Solution

The implementation of a system that utilizes a master and slave server setup with a RAID-0 striping approach, where data is dynamically relocated and virtualized using a translation table to maintain redundancy and availability, allowing continued access without re-mirroring the entire data set upon disk failure, thereby reducing wear-out rates and latency.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional replication processes are used to recover from disk failure, then data redundancy is maintained, but resource consumption and time required for recovery increase significantly

Engineering Contradiction:
Improvedata redundancyVSAvoidrecovery time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary actions by maintaining a translation table that maps logical block addresses to physical storage locations across multiple disks before failure occurs. When a disk fails, the system can immediately redirect I/O operations to remaining healthy disks using pre-computed mappings, eliminating the need for time-consuming full data set replication and enabling rapid recovery while maintaining data redundancy

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system segments the storage system into independent disk units with individual failure modes. Instead of treating the entire storage array as a single unit that must be fully replicated upon failure, the patent allows individual disk failures to be handled independently through translation table remapping, enabling partial system operation and reducing overall recovery time while maintaining data redundancy through distributed storage across segmented disk units

Inventive Principle:
Principle #1Segmentation

2Reliability

If full data set replication is performed upon disk failure, then data integrity is restored, but resource intensive operations and errors increase

Engineering Contradiction:
Improvedata integrityVSAvoidresource efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system extracts only the necessary mapping information from the failed disk's data structure and stores it in a translation table, rather than replicating the entire data set. This extraction approach allows the system to maintain data integrity by preserving the logical-to-physical address mappings while avoiding the resource-intensive full replication process, thereby improving resource efficiency without compromising data integrity

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

Instead of copying entire data sets for replication, the system creates a lightweight copy of the translation table that maps logical block addresses to physical locations on remaining healthy disks. This minimal copying approach restores data integrity by enabling continued access to all data through alternative physical paths while consuming significantly fewer resources than full data set replication

Inventive Principle:
Principle #26Copying

3Reliability

If the entire server is taken offline upon disk failure, then data safety is ensured, but service availability and access time decrease

Engineering Contradiction:
Improvedata safetyVSAvoidservice availability
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The system dynamically adapts to disk failures by updating the translation table in real-time to reflect current disk availability. When a disk fails, the translation table is remapped to redirect I/O operations to remaining healthy disks without requiring server shutdown. This dynamic adaptation maintains data safety through continued redundancy checks while preserving service availability, allowing the server to remain online and operational throughout the failure recovery process

Inventive Principle:
Principle #15Dynamics

4Reliability

If traditional failover processes are used, then system reliability is maintained, but overhead and complexity increase

Engineering Contradiction:
Improvesystem reliabilityVSAvoidfailover overhead
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system introduces a translation table as an intermediary layer between the host system and physical storage disks. This translation table absorbs the complexity of failure detection, address remapping, and redundancy management, providing a simple interface to the host while handling complex failover operations transparently. The intermediary approach maintains system reliability through automated remapping while reducing failover overhead by eliminating the need for complex coordinated failover protocols across multiple system components

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS11106550B2Block storage relocation on failure
Publication Date: 2021.08.31 AMAZON TECH INC
  • US11106550B2 patent drawing
  • US11106550B2 patent drawing
  • US11106550B2 patent drawing

AI summary

A failure of a storage device used to provide a mirrored storage volume can be managed without a full re-mirroring of the volume. The volume can be provided using a set of similar storage devices on each of a master server and a slave server, and a technique such as data striping can be used to store the data for the volume across the various devices. When a storage device becomes unavailable, the data from the corresponding storage device on the other mirrored server can be written to the remaining storage devices on the server experiencing the device failure. The data interface can be virtualized such that the user can continue to send input and output (I/O) requests using the same address information. A translation layer can map the virtualized addresses to the physical addresses where the data is stored.