Hash File System Restore Speed via Pre-stored Data Addresses

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional Content Addressed Storage (CAS) systems require multiple seek operations during data restoration, which slows down the process and increases the time required to retrieve data.

Innovation Solution

Storing data addresses with composite or directory element recipes in a hash file system reduces the number of seek operations by pre-recording storage addresses, allowing for immediate population of a cache with unique identifiers and addresses during restoration.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional CAS systems perform multiple seek operations during data restoration, then data integrity is maintained, but restore speed decreases and restoration time increases

Engineering Contradiction:
Improvedata integrityVSAvoidrestore speed
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent applies preliminary action by pre-calculating and storing the storage addresses of child data objects within the parent object data structure during the backup process. This allows the restore operation to directly access all required data without performing multiple seek operations, thereby maintaining data integrity while significantly improving restore speed

Inventive Principle:
Principle #10Preliminary action

2Measurement precision

If multiple seek operations are performed during data restoration in CAS systems, then accurate data location is ensured, but the time required for restoration increases

Engineering Contradiction:
Improvedata location accuracyVSAvoidrestoration time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The patent performs preliminary action by embedding storage address information within the parent object data structure during data ingestion. This pre-stored address information eliminates the need for multiple sequential seek operations during restoration, maintaining precise data location accuracy while reducing restoration time

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The parent object data structure serves as an intermediary that contains both the hash values and storage addresses of child data objects. This intermediary structure allows the system to directly locate data without performing multiple seek operations, thereby reducing restoration time while maintaining location accuracy

Inventive Principle:
Principle #24Intermediary (Mediator)

3Productivity

If storage addresses are pre-recorded with parent objects, then restore speed increases, but data structure complexity increases

Engineering Contradiction:
Improverestore speedVSAvoiddata structure complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent merges the storage address information with the parent object data structure, combining what would otherwise be separate pieces of information into a single integrated structure. This eliminates the need for separate index structures or metadata tables, thereby improving restore speed without significantly increasing overall system complexity

Inventive Principle:
Principle #5Merging (Combining)

Data Source

PatentUS7949630B1Storage of data addresses with hashes in backup systems
Publication Date: 2011.05.24 EMC IP HLDG CO LLC
  • US7949630B1 patent drawing
  • US7949630B1 patent drawing
  • US7949630B1 patent drawing

AI summary

Seek operations required to perform restore processes at an HFS server are reduced by storing storage addresses of data associated with hash values included in recipes with the recipes. In a typical embodiment, an HFS server receives a recipe for entry into a hash file system and performs a reference check on the recipe to avoid data corruption. This includes using hash values of the associated data to lookup storage addresses for the associated data in corresponding index stripes. The identified storage addresses can be appended to/stored with the recipe when the recipe is stored by the HFS server. Later during a restore process, retrieval of the recipe also retrieves the storage addresses without having to look up the storage addresses in the corresponding index stripes. Consequently, seek operations during restore can be cut in half and the speed of performing the restore can be doubled.