Vectored Block-Level Checksum for File System Data Integrity

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current file systems lack robust mechanisms for efficiently managing and verifying data integrity across storage pools, particularly in ensuring data blocks are not corrupted and in optimizing storage allocation strategies.

Innovation Solution

Implementing vectored block-level checksums within the file system, where data blocks and their checksums are stored separately, allowing for per-block checksum functions and robust fault isolation, and using a storage pool allocator to manage storage space efficiently.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If checksums are stored adjacent to data blocks in the file system, then data integrity verification is enabled, but storage space is wasted and retrieval efficiency is reduced due to sequential access requirements

Engineering Contradiction:
Improvedata integrity verificationVSAvoidretrieval efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent separates checksums from data blocks into different storage locations. Checksum blocks are stored independently from data blocks in the storage pool, allowing parallel access during verification operations. This segmentation eliminates the sequential access bottleneck while maintaining data-integrity verification capability.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces an indirect block structure that acts as an intermediary between the file system and physical storage. This indirect block contains metadata including checksum information, enabling efficient retrieval paths without requiring direct adjacency of checksums and data blocks on the storage medium.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If a single checksum function is used for all data blocks, then implementation is simple, but adaptability to different data types and integrity requirements is limited

Engineering Contradiction:
Improvechecksum function selectionVSAvoidchecksum management
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements dynamic checksum function selection where the checksum function is not fixed but can be chosen based on data characteristics, storage location, and integrity requirements. The system can select from multiple checksum functions (e.g., CRC32, MD5, SHA-1) depending on the specific needs of each data block, providing adaptability while managing complexity through structured selection criteria.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent changes the parameter of checksum function selection from a fixed value to a variable that can be adjusted based on data type, storage pool characteristics, and integrity requirements. This allows the system to optimize checksum selection for different scenarios (e.g., faster CRC for non-critical data, more robust SHA-1 for critical data) without requiring a completely different system architecture.

Inventive Principle:
Principle #35Parameter changes

3Ease of operation

If the volume manager organizes data along volume boundaries on physical disks, then volume management is simplified, but the file system cannot efficiently utilize free space across multiple physical disks

Engineering Contradiction:
Improvevolume managementVSAvoidstorage space utilization
Core Design Contradiction:
Ease of operationVSProductivity

Solution Approach 1:

The patent introduces a new dimension of abstraction by implementing a storage pool that sits above the volume manager layer. This storage pool aggregates free space from multiple volumes and physical disks into a unified addressable space, allowing the file system to allocate data across disk boundaries without requiring the volume manager to reorganize data along volume boundaries. This resolves the conflict by adding a higher-level coordination layer.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

Solution Approach 2:

The storage pool serves multiple functions: it acts as a unified allocation space for the file system, a coordination layer for cross-disk data placement, and a mechanism for implementing checksum separation. This multi-functionality allows the system to maintain simple volume management while achieving efficient storage utilization across multiple physical disks.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS7415653B1Method and apparatus for vectored block-level checksum for file system data integrity
Publication Date: 2008.08.19 ORACLE AMERICAN INC
  • US7415653B1 patent drawing
  • US7415653B1 patent drawing
  • US7415653B1 patent drawing

AI summary

A method for storing a data block, involving storing the data block in a storage pool, obtaining a data block location, determining a checksum function for the data block, calculating a data block checksum using the checksum function for the data block, and storing a first indirect block in the storage pool, wherein the first indirect block comprises the data block location, the data block checksum, and a checksum function ID corresponding to the checksum function for the data block.