device-mapper-utils/blk-stash

Handle/Cope with damaged archive

Open

#15 opened on Jul 23, 2025

View on GitHub
 (0 comments) (0 reactions) (0 assignees)Rust (1 fork)auto 404
help wanted

Repository metrics

Stars
 (0 stars)
PR merge metrics
 (PR metrics pending)

Description

Handle/Cope with damaged archive

Summary

We need to robustly handle cases where a blk-archive archive is partially damaged—due to disk errors, bit rot, interrupted writes, or corruption. This is a major piece of work that must be addressed before finalizing the archive and slab file formats, as it will likely require additional metadata for recovery and diagnostics.

This issue may need to have multiple sub-issues.

Goals

  • Assess how the system currently behaves in the face of damage to slab or metadata files
  • Design mechanisms to detect and isolate damaged regions
  • Add necessary metadata to support recovery and partial restoration
  • Ensure that when damage occurs, useful diagnostics and error reports are available
  • Test with a wide range of corruption scenarios
  • Corruption should also include the handling of meta-data text files used in the archive and the ramifications of them being corrupted too

Tasks

  • Design a fault model: simulate various types and sizes of damage in different archive files
    • Bit flips
    • Zeroed regions
    • Truncated files
    • Overwritten sections
  • Identify which internal components are most vulnerable
  • Add integrity metadata to slab files if missing (e.g., checksums, offsets, chunk-level boundaries)
  • Create tooling or tests to simulate damage and verify detection
  • Report which chunks or data streams are lost or unverifiable
  • Ensure the system can continue operating in degraded mode if possible (e.g., skip damaged slabs)
  • Provide detailed output about damage extent and affected data
  • Consider introducing a --rescue mode for partial extraction

Considerations

  • Do not finalize slab/archive formats until this work is complete
  • Design metadata to aid in both damage detection and recovery
  • Aim for minimal metadata overhead while maximizing recoverability
  • Ensure recovery metadata is versioned and forward-compatible

Potential Features

  • Per-chunk or per-slab checksums
  • Stream index redundancy or duplication
  • Clear separation of recoverable vs. unrecoverable damage in output

Benefits

  • Improves robustness and trustworthiness of archive format
  • Enables use in long-term storage or less reliable environments (e.g., tape, cloud)
  • Supports better tooling for backup verification and corruption auditing

Contributor guide